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is  the  first  in  a  series  of  three  Integrated  AUTODIN 
Systems  Architecture  (IASA)  Reports,  addressing  the  1978-1983  (near-term) 
implementation  alternatives  for  the  Integrated  AUTODIN  System. 

2.  Applicability .  The  user  is  cautioned  in  the  use  of  this  report.  Most 
of  this  report  has  been  updated  by  the  IASA  Report,  Part  2,  dated  March 
1979.  Nearly  all  the  milestones,  schedules,  and  deployment  figures  have 
been  changed  in  the  Part  2  Report.  The  Part  1  Report  addresses  the  near- 
term  in  greater  detail  than  the  Part  2  Report,  and  is  useful  to  the  user 
as  background  information. 

3.  Approval .  The  IASA  Report,  Part  1,  dated  December  1977  was  approved 
by  the  Assistant  Secretary  of  Defense,  Command,  Control,  Communications, 
and  Intelligence  (ASD/C^I)  in  October  1978.  Together  with  this  approval, 
the  DCA  was  directed  to:  (1)  identify,  develop  and  promulgate  necessary 
standards;  (2)  identify  the  roles  and  relationships  of  components  of  the 
Integrated  AUTODIN  System;  (3)  establish  an  Inter-Serviee/Agency  AMPE 
Program;  and  (4)  complete  the  development  of  functional  specifications 
for  the  common  family  of  terminals. 

4.  Definition  Changes.  Reference  to  the  Local/Regional  Access  Node  (LRAN) 
and  the  Centralized  Service  Facility  (CSF)  should  be  deleted.  The  I-S/A 
AMPE  provides  the  functional  capabilities  projected  for  these  concepts. 

5.  Architecture .  The  nodal  functions  of  the  existing  AUTODIN  Switching 
Centers  (ASCs)  have  been  combined  with  AMPE  functions  to  provide  a  network 
access  element  now  designated  the  Inter-Service /Agency  AMPE  (I-S/A  AMPE). 
The  AUTODIN  I  ASCs  will  be  phased  out  by  "phasing  in"  three  or  more  I-S/A 
AMPEs  on  a  regional  basis  to  service  the  AUTODIN  I  subscribers  then  con¬ 
nected  to  the  ASC.  The  IAS  Architecture  provides  for  a  Common  Family  of 
Network  Elements  (CNFE)  which  includes  the  I-S/A  AMPE,  the  DoD  AUTODIN 
Subscriber  Terminal  (DAST)  Family,  and  the  DoD  Standard  Network  Front  End 
(SNFE),  AUTODIN  Switches,  among  other  IAS  element  configurations. 

6.  Availability  of  Report.  This  report  has  been  placed  in  the  Defense 
Technical  Information  Center  (DTIC)  and  may  be  ordered  under  AD- 

The  DTIC,  formerly  the  Defense  Documentation  Center  (DDC),  is  located  at 
Cameron  Station,  Alexandria,  VA  20315. 

7.  Point  of  Contact.  For  further  information  on  the  applicability  and 
content  of  the  IASA  reports,  the  point  of  contact  is  Mr.  C.I.  Eisiminger, 
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EXECUTIVE  SUMMARY 


This  report  identifies  near-term,  1978-1983,  Automatic 
Digital  Network  (AUTODIN)  implementation  alternatives  and 
recommendations  to  meet  user  needs  for  common-user  record 
and  data  communications.  It  provides  the  framework  for  the 
evolutionary  development  of  an  Integrated  AUTODIN  System 
(IAS)  on  a  terminal-to-terminal  basis  to  include  architec¬ 
tural  design  considerations  for  post  1983. 

The  purpose  of  the  Integrated  AUTODIN  System  Architecure 
(IASA)  is  to  guide  the  evolution  of  telecommunications  systems 
toward  a  more  efficient  means  of  message  processing  and 
data  communications  while  offering  standard  solutions  to 
user  requirements. 

On  5  February  1975,  OSD/DTACCS  (now  ASD/C^I)  tasked  the 
Defense  Communications  Agency  (DCA)  in  coordination  with  the 
Services/Agencies,  to  develop  an  IASA  on  a  terminal-to- 
terminal  basis  and  based  on  the  architecture  to  define  a 
common  family  of  AUTODIN  terminal  hardware  and  software. 

On  12  December  1975,  OSD/DTACCS  approved  the  DCA  IASA  develop¬ 
ment  plan.  As  a  result  of  this  plan,  DCA  is  responsible  for 
accomplishing  three  objectives:  (1)  develop  a  system  archi¬ 
tecture  on  a  terminal-to-terminal  basis;  (2)  develop  terminal 
specifications;  and  (3)  develop  related  standards,  formats, 
and  procedures. 

The  overall  objective  of  the  IASA  project  is  to  design 
and  engineer  a  DoD-wide  common-user  system  for  communicating 
narrative  and  data  traffic,  for  the  period  1978  to  1990, 
based  upon  AUTODIN  I  and  AUTODIN  II,  which  is  complete  and 
integrated  from  end  to  end.  The  1978-1983  implementation 
alternatives  include  determining  the  number  and  location  of 
AUTODIN  I  Switching  Centers  (ASCs) ,  AUTODIN  II  Packet  Switch¬ 
ing  Nodes  (PSNs) ,  AMPEs,  and  user  terminals.  The  1984  to 
1990  time  frame  will  see  the  implementation  of  new  hardware/ 
software  elements  to  replace  obsolete  equipments.  The  planning 
of  a  smooth  transition  over  the  1978-1990  time  frame  is  one  of 
the  important  aspects  of  the  IAS  architectural  strategy  and  is 
developed  throughout  this  report.  In  addition  to  major  network 
elements,  this  report  covers  such  topics  as  user  requirements, 
data  communications  trends,  standards,  security,  integration 
of  the  WWMCCS  Intercomputer  Network  (WIN)  into  AUTODIN  II,  and 
the  IAS  transition  strategy.  Figure  10,  page  94,  provides  the 
IAS  transition  strategy  for  the  period  1978  to  1990. 
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The  following  time  periods  have  been  assigned  to  the 
various  parts  of  the  IASA  project: 

1.  Near  term:  1978-1983. 

a.  Deployment  of  AUTODIN  II  packet  switches  in  CONUS 
and  to  a  limited  extent  overseas. 

b.  Thinning  of  AUTODIN  I  switch  population. 

c.  Complete  deployment  of  the  current  generation  of 
AMPEs  in  1982  with  further  access  area  needs  provided  by  an 
Inter-Service/Agency  AMPE,  which  can  serve  all  DoD  users  in 
an  area  and  interface  either  AUTODIN  I  or  AUTODIN  II  switches. 

d.  Deployment  of  a  common  family  of  AUTODIN  terminals 
based  upon  functional  specifications. 

2.  Mid  term:  1984-1988. 

a.  Further  deployment  of  AUTODIN  II  switches  overseas. 

b.  Phase-out  of  AUTODIN  I  switches. 

c.  Provision  for  AUTODIN  I  unique  functions  in 
either  an  augmented  Inter-Service/Agency  AMPE  or  a  Centralized 
Service  Facility  associated  with  AUTODIN  II  nodes  or  both. 

3.  Far  term:  1989-Future.  A  third  generation  data  system 
to  be  defined  in  conjunction  with  the  other  third  generation 
subsystems  of  the  DCS. 

This  report  (Part  1)  provides  AUTODIN  implementation 
alternatives  through  1983  and  preliminary  architectural 
information  for  the  post-1983  period.  Section  V  provides 
conclusions  and  recommendations  to  this  IASA  project  report. 

In  January  1979,  Part  2,  architectural  alternatives  for  the 
period  1984  to  1990  will  be  provided.  In  August  1979,  Part  3, 
functional  specifications  for  a  common  family  of  AUTODIN 
terminals  will  be  provided. 
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SECTION  I 


INTRODUCTION 


A.  Purpose .  This  report  identifies  near  term,  1978-1983, 
Automatic  Digital  Network  (AUTODIN)  implementation  alternatives 
and  recommendations  to  meet  user  needs  for  common-user  record 
and  data  communications.  It  provides  the  framework  for  the 
evolutionary  development  of  an  Integrated  AUTODIN  System  (IAS) 
on  a  terminal-to-terminal  basis  to  include  architectural 
design  considerations  for  post  1983. 

The  purpose  of  the  IAS  Architecture  is  not  to  create  a 
new  system  to  be  superimposed  on  all  other  user  systems  in 
a  duplicative  way,  nor  is  it  to  exploit  technological  advances 
in  the  data  processing  industry  when  there  is  no  well  defined 
need  to  do  so.  The  purpose  of  the  IASA  is  to  guide  the 
evolution  of  telecommunications  systems  towards  a  more  secure, 
accurate,  survivable,  and  efficient  means  of  message  process¬ 
ing  and  data  communications  while  offering  standard  solutions 
to  user  requirements. 

B.  Background .  In  July  1974,  the  General  Accounting  Office 
(GAO)  published  a  report  that  was  critical  of  the  Department 
of  Defense  (DoD)  for  (1)  not  having  a  single  agency  responsi¬ 
ble  for  management  of  the  entire  AUTODIN  system  to  include 
AUTODIN  terminals;  (2)  for  a  poor  telecommunications  center 
consolidation  record;  and  (3)  for  duplication  of  effort  and 
proliferation  of  LDMX-type  AUTODIN  terminals  by  the  Military 
Departments  (MILDEPs)  and  DoD  Agencies.  The  GAO  recommended 
to  OSD/DTACCS  (now  ASD/CCCI)  that  a  single  AUTODIN  manager  be 
appointed  to  resolve  the  problems  as  they  surfaced. 

On  5  February  1975,  OSD/DTACCS  acted  on  the  GAO  recom¬ 
mendation  by  tasking  the  Defense  Communications  Agency  (DCA) 
in  coordination  with  Services/Agencies,  to  develop  an 
Integrated  AUTODIN  System  Architecture  (IASA)  on  a  terminal- 
to-terminal  basis  and  based  on  that  architecture  to  define  a 
common  family  of  AUTODIN  terminal  hardware  and  software. 
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On  12  December  1975,  OSD/DTACCS  approved  the  DCA  IASA 
development  plan  which  would  address  the  backbone, 
concentrators,  and  terminals  as  a  single  integrated 
system  with  processing  functions  allocated  to  system 
components  on  the  basis  of  how  and  where  they  can  best 
be  performed.  As  a  result  of  this  plan,  DCA  is  responsible 
for  accomplishing  three  objectives:  (1)  develop  a  system 
architecture  on  a  terminal-to-terminal  basis;  (2)  develop 
terminal  specifications;  and  (3)  develop  related 
standards,  formats,  and  procedures. 

As  an  outgrowth  of  the  OSD  tasking,  JCS  Memorandum 
of  Policy  165,  titled:  AUTODIN  and  Associated  Message 
Processing  Systems,  was  issued  on  5  May  1976.  MOP  165 
establishes  AUTODIN  as  the  DoD  common-user  data 
communications  system,  directs  maximum  use  of  the 
system  elements,  identifies  criteria  for  interservice 
telecommunications  center  consolidation  and  automation, 
provides  safeguards  to  prevent  proliferation  of 
non-standard  terminal  systems,  and  provides  policy  and 
guidance  for  use  of  new  equipments  using  automation 
techniques  through  the  AUTODIN. 

C.  Organization.  The  IASA  Project  organization  is 
shown  in  Figure  1.  Control  of  the  project  is  exercised 
through  the  AUTODIN  Systems  Integration  Branch  (Code  534) , 
Headquarters  DCA.  Technical  Support  is  provided  by  the 
Defense  Communications  Engineering  Center  (DCEC) . 
Representatives  of  DCA,  MILDEPs,  National  Security  Agency 
(NSA) ,  Defense  Intelligence  Agency  (dia) ,  and  Defense 
Logistics  Agency  (DLA)  are  formed  into  a  Technical/Policy 
Panel  which  serves  as  the  forum  for  discussion  of  IASA 
issues.  In  addition,  there  are  four  working  groups,  each 
chaired  by  DCA,  with  participation  from  MILDEPs  and  DoD 
Agencies. 

The  IASA  Project  working  groups  were  established  to 
develop  the  required  design  baseline  inputs.  The  Security 
Working  Group  objective  is  to  insure  that  user  security 
requirements  are  factored  into  the  IASA.  The  User  Needs 
and  Capabilities  Working  Group  objective  is  to  develop  a 
data  base  containing  user  functional  requirements  and 
capabilities  and  to  perform  a  detailed  analysis  of  the 
various  Automated  Message  Processing  Exchanges  (AMPEs) . 


The  Standards  and  Procedures  Working  Group  objective  is 
to  develop  policy,  procedures,  and  standards  for  message 
preparation,  input,  transmission,  output,  and  distribution 
facilities.  The  Target  Environment  Working  Group  objective 
is  to  provide  a  description  of  technical,  economic,  and 
organizational  factors  that  influence  the  IASA  development. 
The  results  of  these  working  group  efforts  are  presented 
in  this  report. 


IASA  PROJECT 
ORGANIZATION 


WORKING  GROUPS 


Figure  1 
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D.  Scope  of  Effort.  The  overall  objective  of  the  IASA 
project  is  to  design  and  engineer  a  DoD-wide  common-user 
system  for  communicating  narrative  and  data  traffic,  for 
the  period  1978  to  1990,  based  upon  AUTODIN  I  and  AUTODIN  II, 
which  is  complete  and  integrated  from  end  to  end.  The  IASA 
design  is  by  necessity  evolutionary  in  development,  with  the 
key  ingredient  being  responsiveness  to  user  needs. 

The  1978-1983  implementation  alternatives  include 
determining  the  number  and  location  of  AUTODIN  I  Switching 
Centers  (ASCs) ,  AUTODIN  II  Packet  Switching  Nodes  (PSNs) , 

AMPEs,  and  user  terminals.  The  near-term  IAS  concerns 
itself  with  what  is  presently  or  soon  to  be  implemented. 

The  1984  to  1990  time  frame,  on  the  other  hand,  will  see 
the  implementation  of  new  hardware/software  elements  to 
replace  obsolete  equipments.  The  architecture  for  these 
new  elements  must  be  developed  during  the  near-term  IAS  in 
order  to  be  available  during  the  post-1983  period. 

The  planning  of  a  smooth  transition  over  the  1978-1990 
time  frame  is  one  of  the  important  aspects  of  the  IAS 
architectural  strategy  and  is  further  developed  throughout 
this  report.  In  addition  to  the  major  network  elements 
previously  stated,  this  report  covers  such  topics  as  user 
requirements,  data  communications  trends,  standards,  baseline 
allocation  of  functions,  security,  and  integration  of  the 
WWMCCS  Intercomputer  Network  (WIN)  into  AUTODIN  II. 

Reference  is  made  to  Figure  2  for  IASA  project  milestones, 
which  logically  divides  the  IASA  project  into  three  parts. 

This  report  (Part  1)  provides  AUTODIN  implementation  alternatives 
through  1983.  In  January  1979,  architectural  alternatives 
(Part  2)  for  the  period  1984  to  1990  will  be  provided.  In 
August  1979,  functional  specifications  (Part  3)  for  a  common 
family  of  AUTODIN  terminals  will  be  provided.  Reference  is 
made  to  Appendix  1  for  list  of  acronyms. 
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SECTION  II 


REQUIREMENTS 


A.  General .  This  section  identifies  user  requirements 
as  they  are  expected  to  exist  in  the  early  1980's.  In 
addition  to  their  importance  in  determining  near-term 
AUTODIN  implementation  strategies,  these  requirements 
will  be  used  as  guidelines  in  architectural  development 
of  the  IAS  for  the  1984  to  1990  time  frame. 

The  extent  to  which  the  IAS  will  provide  increased 
user  satisfaction  over  the  AUTODIN  system  of  today  is  a 
function  of  several  factors.  For  instance,  the  AUTODIN  II 
system  and  the  AMPEs  are  being  fielded  primarily  because 
AUTODIN  I  does  not  effectively  meet  user  requirements. 

In  addition,  the  advancing  state-of-the  art  in  technology 
offers  considerable  promise  of  increased  capability  at 
reduced  costs.  To  aid  in  understanding  these  technological 
changes,  an  assessment  of  the  data  communications  environment 
of  the  1980's  will  be  provided  in  this  section.  In  general 
terms,  increased  user  satisfaction  will  result  from: 

.  Improved  wr iter-to-reader  speed-of-service . 

.  Improved  telecommunications  center  operations. 

.  Improved  system  responsiveness  to  crisis  management. 

.  Improved  system  responsiveness  to  data  users. 

.  Increased  transparency  of  information  processed 
throughout  the  network. 

In  conjunction  with  these  IASA  objectives,  standards  are 
discussed  with  additional  information  provided  in  Section  III.  D. 

B.  Evolving  Data  Communications  Environment.  Viewed  in 
the  perspective  of  the  IAS  1983  time  frame,  no  one  can 
predict  with  confidence  what  the  data  communications 
environment  will  be  in  the  mid  80's.  The  AUTODIN  system 
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d-  sign  is  complicated  I  cause  we  canr.  •  start  t  a  zei 
baseline,  but  must  be  able  to  merge,  integrate,  replace  sub¬ 
systems,  stretch  out  the  old  when  it  is  more  cost-effective, 
and  add  new  capabilities  in  an  evolutionary  manner. 

1.  Information  Systems.  In  addition  to  the  traditional 
areas  of  command  and  control,  intelligence  gathering, 
logistics,  and  personnel  management,  emerging  information 
systems  are  finding  application  in  a  wide  variety  of 
situations  requiring  the  rapid  assimilation  and/or 
processing  of  information  affecting  many  other  aspects 
of  defense  management.  As  technology  changes,  so  do 
the  concepts  by  which  we  understand  the  content  of 
information  and  the  need  for  its  transfer  from  one  point 
to  another.  For  many  systems,  computer  and  terminal 
facilities  are  being  located  at  widely  dispersed 
geographic  points,  and  therefore  large  volumes  of 
information  must  be  transferred  between  these  facilities. 

In  addition,  a  need  is  rapidly  emerging  in  response  to 
the  evolving  complexities  of  our  rperati '■o  exchange 
information  between  traditionally  isolated  sy.  terns  on  a 
more  or  less  routine  basis. 

a.  Within  the  DoD  community,  two  related  develop¬ 
ments  could  have  considerable  impact  on  the  near-term  IAS: 

(1)  The  advantages  of  consolidating  ADP  and 
telecommunications  functions  is  gaining  wider  recognition 
within  the  DoD  management  structure . 

(2)  The  economies  which  can  be  achieved  through 
automation  in  the  various  areas  of  traditional  management 
functions  are  giving  new  impetus  to  the  development  of  com¬ 
plex  management  information  processing  systems. 

The  ADP  and  telecommunications  fields  have  developed 
independently;  each  has  maintained  its  own  separate  ident¬ 
ity,  discipline,  doctrine,  and  terminology.  The  current 
need,  however,  for  the  acquisition  and  sharing  of  highly 
dispersed,  nonhomogeno as ,  time-sensitive  data  has  resulted 
in  a  growing  concern  on  the  part  of  both  fields  of  interest 
for  the  need  to  develop  an  information  systems  approach 
to  solving  the  common  problems  arising  from  internetting. 
There  is  a  growing  awareness  of  the  need  to  merge  ideas 
and  practices  in  order  to  create  viable  integrated  infor¬ 
mation  systems  rather  than  continue  with  the  maintenance  of 
two  separate  fields. 


b.  While  there  is  a  trend  toward  consolidating 
"teleprocessing"  functions,  the  vastly  greater  accumu¬ 
lations  of  information  made  possible  by  the  available 
technology  is  creating  a  current  demand  for  a  more 
sophisticated  communications  network  than  that  presently 
available  within  the  current  message  switching  environment. 

This  sophistication  of  communications  demand  arises  from 
several  factors: 

(1)  ADP  systems  are  no  longer  being  implemented 
in  isolation  of  one  another  but  are  being  consolidated  and 
interconnected  within  a  complex  arrangement. 

(2)  Rapid  response  times  normally  associated 
with  priority  matters  affecting  the  national  security 
are  now  required  on  a  regular  basis  for  matters  affecting 
management  efficiency.  In  particular,  the  philosophy  of 
the  new  management  information  systems  is  to  record 
information  into  computer  format  for  electrical 
transmission  at  the  information  source,  thereby  avoiding 
duplication  in  effort  and  time  lags  inherent  in  the  more 
conventional  acquisition  of  information. 

(3)  The  extent  of  the  problems  related  to 
the  new  information  handling  systems  is  resulting  in  a 
substantial  increase  in  the  requirement  for  bulk  data 
transfer  with  associated  handling  efficiencies  which 
cannot  be  achieved  within  the  existing  switched  networks. 

(4)  With  the  increasing  complexity  of  DoD 
management  decisions,  as  well  as  those  of  government  and 
the  business  community  as  a  whole,  the  need  for  collecting 
vast  quantities  of  data  to  support  complex  resource  manage¬ 
ment  allocations  and  decisions  is  becoming  more  and  more 
essential  to  orderly  government  operation.  Accordingly, 
there  will  be  a  considerable  increase  in  the  volume  as 
well  as  type  of  traffic  handled  by  the  data  communications 
networks  of  the  future . 

2.  Trends.  The  following  are  some  of  the  forecasted 
trends  for  the  1980's: 

a.  The  requirement  to  move  more  information  in  a 
shorter  time  span  will  be  reflected  in  greatly  enhanced 
efforts  to  automate  source  data  entry  at  the  communications 
terminal  with  direct  voice/data  input  offering  the  greatest 
system  improvement. 
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b.  To  reduce  access  line  costs,  the  primary 
interface  between  the  user  and  the  long-haul  communications 
network,  at  least  for  major  military  installations,  will  be 
a  large  base  concentrator (s) .  These  concentrators  will 
provide  a  significant  improvement  over  those  currently 
available  in  providing  true  "user-to-user"  multi-media 
communications  service. 

c.  The  separate  functional  areas  of  telecommunications, 
data  automation,  and  resource  management  will  be  merged 

into  one  area  treating  information  creation,  processing, 
and  resource  management  transfer  as  an  integrated  whole. 

d.  Developments  in  large  scale  integrated  circuits 
and  plasma  display  technologies  offer  considerable  potential 
for  new  teleprocessing  applications. 

e.  Routine  clerical  functions  such  as  file 
updating,  text  correcting,  dictation,  etc.,  will  be  performed 
on  a  routine  basis  by  the  teleprocessing  system  -  often 

from  the  central  file. 

f.  The  fact  that  personnel  costs  constitute  the 
bulk  of  the  annual  increment  of  life  cycle  costs  for 
administrative  type  services  will  be  the  major  driving 
force  for  conversion  to  ADP  operation. 

g.  Multiple  copies  of  manuals  and  other  bulky 
documentation  will  be  reduced  to  a  single  control  file 

with  electrical  access  and  peripheral  reproduction  capability. 
The  transfer  of  the  large  volumes  of  data  associated  with 
this  concept  will  be  facilitated  by  the  increased  bandwidth 
available  for  bulk  data  transfer  and  the  application  of 
"slow  scan"  techniques  together  with  "cheap"  terminal  storage. 

h.  In  order  to  increase  both  employee  and  management 
productivity,  more  and  more  personnel  will  have  communications 
terminals  at  their  desks. 

i.  With  the  increasing  deterioration  of  mail  service 
as  volume  grows  and  transportation  and  handling  costs 
increase,  facsimile  "mail"  will  likely  become  a  much  more 
attractive  alternative  to  current  operations  and  will  place 

a  substantial  demand  on  the  IAS. 

j.  With  the  availability  of  larger  bandwidths , 
facsimile  may  be  coupled  directly  to  the  office  copiers 
and  operated  at  compatible  speeds. 
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k.  The  use  of  the  Touchtone  telephone  as  a  cheap 
computer  terminal  with  voice  answerback  or  a  coupled  digital 
display,  will  greatly  expand  teleprocessing  applications. 

l.  Optical  processors  will  greatly  enhance  pattern 
recognition,  associative  processing,  and  other  areas  in  which 
a  very  large  number  of  different  data  elements  must  be 
correlated. 


m.  World  patterns  will  change  as  screen-to-screen 
communications  (teleconferencing)  proves  to  be  an  attractive 
alternative  to  business  travel. 

n.  Extremely  large  computer  files  (data  banks)  will 
be  available  in  which  every  item  stored  can  be  retrieved  in 
a  fraction  of  a  second.  Banks  of  data  on  many  subjects  will 
grow  to  the  extent  that  computers  will  be  used  as  "librarians: 
for  aiding  in  the  worldwide  search  for  particular  items  of 
information. 


o.  Computers  will  drop  in  costs  at  a  faster  rate  than 
communications  lines.  To  some  extent,  this  trend  will  counter 
the  trend  towards  increased  use  of  data  transmission  (i.e., 
greater  decentralization) . 

C.  Functional  Requirements.  In  order  to  meet  user  require¬ 
ments  of  the  1980's,  the  IASA  must  improve  speed  and  quality 
of  telecommunication  service  while  decreasing  costs.  The 
following  paragraphs  identify  functional  requirements  which 
the  IASA  must  satisfy: 

1.  Improvement  of  Writer-to-Reader  Speed  of  Service  and 
Reduction  In  Telecommunications  Manpower^  An  important 
objective  of  the  IASA  is  to  develop  a  system  which  provides 
improved  writer-to-reader  speed  of  service  and  improved  quality 
of  service  with  the  same  manpower  or  less.  This  objective 
suggests  a  requirement  for  automation  at  those  points  in  the 
system  where  delays  occur  because  of  queues  for  human  inter¬ 
vention,  and  where  manpower  intensive  tasks  are  performed. 

Writer  to  reader  speed  of  service  is  subject  to  delays  outside 
the  realm  and  control  of  telecommunications.  Therefore,  the 
inter-relationship  between  administration  and  telecommunications 
should  be  addressed. 


a.  Plain  Language  Entry.  In  order  to  exploit 
Optical  Character  Reader  Equipment  (OCRE) ,  narrative 
users  must  be  provided  the  capability  to  enter  a  message 
into  AUTODIN,  either  directly  or  through  a  telecommunications 
center,  using  a  plain  language  address.  This  capability 

now  exists  only  through  manual,  semi -automated,  or 
automated  conversion  of  the  plain  language  address  to  a 
routing  indicator  (PLA-RI)  at  the  telecommunications  center. 
The  IASA  must  provide  automation  of  this  conversion  process 
somewhere  in  the  system  or  obviate  the  need  for  conversion 
by  using  the  plain  language  address  or  other  writer-provided 
data  as  the  routing  means  throughout  the  system. 

b.  Internal  Routing  Determination  and  Preparation 
for  Distribution.  This  function,  now  performed  by  the  user 
after  delivery  of  the  message,  must  be  automated  within  the 
system  if  the  system  is  to  be  responsive  to  writer-to-reader 
requirements.  Decision  logic  tables  are  now  used  in  AMPEs 
to  make  internal  routing  determination  and  subsystems  are 
now  available  which  prepare  messages  for  distribution. 

This  function  must  be  standardized  and  assigned  to  a  specific 
element  of  the  architecture.  Moreover,  standards  must  be 
established  which  will  permit  automated  internal  distribution 
determination  to  be  optimized. 

2 .  Improvement  of  Telecommunications  Center  Operations. 

As  various  telecommunications  center  functions  are  automated 
to  reduce  manpower  requirements  and  to  improve  speed  of 
service,  telecommunications  center  operations  will  be  improved 
through  simplification.  Tape  cutting  and  PLA-RI  conversion 
will  be  virtually  eliminated  and  the  function  of  the  internal 
routers  will  be  significantly  reduced.  However,  other 
requirements  which  tend  to  complicate  operations  will  persist. 
Among  these  are  file  and  retrieval,  message  reproduction  and 
distribution  and  the  maintenance  of  traffic  statistics. 

a.  File  and  Retrieval.  These  functions  are  now 
performed  in  various  ways  depending  upon  the  predominant 
traffic  media,  the  equipment  available  and  the  customer 
demand  for  retrieval.  In  some  cases,  only  header  information 
is  filed  and  retrieval  is  accomplished  by  request  to  the  ASC. 
In  telecommunications  centers  with  h  magnetic  tape  capability 
narrative  messages  are  usually  filed  in  their  entirety  and 
retrieval  is  performed  locally.  At  some  telecommunications 
centers  a  user  requirement  exists  to  retrieve  all  referenced 
messages  prior  to  delivery  of  an  incoming  message;  hardcopy 
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filing  is  normal  in  these  cases.  Where  necessary,  the 
I ASA  effort  should  provide  standardization  through  the 
use  of  nodal  facilities  to  serve  manual  telecommunications 
centers,  and  local  filing  where  the  capability  exists. 

The  requirement  for  reference  retrieval  should  be 
questioned  and,  if  valid,  the  referencing  of  messages 
should  be  standardized  and  formatted  to  facilitate 
automated  retrieval . 

b.  Message  Reproduction  and  Distribution.  Message 
reproduction  is  now  a  manual  operation  at  most  telecommuni¬ 
cations  centers.  Three  methods  of  reproduction  are  predomi- 
nent:  the  use  of  reproducible  mats,  the  use  of  manifold 

forms  in  reception  and  xerograph  methods.  Of  these,  only 
xerography  lends  itself  to  automation.  Navy  has  acquired  a 
system  which  xerographically  reproduces  incoming  messages 
and  distributes  to  allocated  bins.  A  system  of  this  nature 
should  be  considered  in  the  IASA  as  a  standard  method  of 
improving  the  performance  of  the  reproduction  and  distribution 
function . 


c.  Maintenance  of  Traffic  Statistics.  This  function 
includes  data  required  for  traffic  management  such  as  queue 
status,  system  availability,  and  terminal  status.  The 
performance  of  this  function  currently  is  dependent  upon  the 
availability  of  processing  power  at  the  telecommunications 
center.  Those  centers  equipped  with  AMPEs  have  fully 
automated  statistics  maintenance;  those  with  smaller 
processors  have  partially  automated  statistics.  Mode  V 
teletype  terminals  and  Digital  Subscriber  Terminal 
Equipments  (DSTE)  generally  depend  upon  manual  statistics 
gathering.  The  need  in  this  area  is  to  standardize  the 
types  of  statistics  gathered,  to  automate  statistic 
gathering  locally  if  possible  and  to  provide  automated 
statistics  gathering  from  AUTODIN  service  centers  or  AMPEs 
for  manual  telecommunications  centers. 


3,  Improve  System  Response  to  Crisis  Management.  AUTODIN 
response  to  crisTs  situations  is  a  function  of  system  surviv¬ 
ability  and  reliability.  Survivability  of  the  current  system 
is  enhanced  through  multiple  homing  and  contingency  alternate 
routing.  Reliability  of  the  AUTODIN  backbone  is  maintained  at 
a  high  state  through  management  by  exception  with  very 
stringent  intervention  points.  Reliability  of  the  system 
terminals  and  access  lines  is  generally  less  than  that  of  the 
backbone  and  is  not  subject  to  the  same  management  techniques. 
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a.  Dual  Homing  and  Contingency  Alternate  Routing. 
Terminals  served  by  the  system  must  have  the  capability  to 
be  made  as  survivable  as  necessary.  This  requirement  is 
now  met  by  multiple  homing  and  contingency  altrouting.  As 
a  minimum,  the  capability  for  multiple  homing  of  terminals 
must  be  retained  to  overcome  the  inherent  vulnerability  of 
a  single  access  line.  Contingency  altrouting  must  be 
provided  within  the  system  either  from  an  ASC  or  at  the 
AMPE  for  connected  remotes  or  at  both  locations .  Diverse 
routing  of  transmission  media  must  be  provided  to  insure 
the  additional  flexibility  needed  to  make  the  IAS  more 
survivable . 

b.  System  Reliability.  The  reliability  of  the 
AUTODIN  backbone,  based  upon  the  factors  of  availability 
and  accuracy,  is  adequate  for  all  foreseeable  requirements. 
The  terminals,  on  the  other  hand,  have  not  demonstrated 
comparable  availability  and  are  more  susceptible  to 
inaccuracy  because  of  line  strikes.  The  IASA  must 
consider  improvement  in  error  detection  and  correction. 

c.  A  design  goal  of  the  IASA  should  be  the 
evolution  of  a  system  which  is,  as  a  minimum,  as  reliable 
as  the  current  backbone.  As  AUTODIN  II  is  deployed  and  the 
IAS  evolves  toward  a  terminal  to  terminal  system,  stringent 
management  thresholds  should  be  maintained  and  extended  to 
all  system  elements.  The  ultimate  goal  should  be  a  99.5% 
availability  intervention  point  applicable  not  only  to  the 
backbone,  but  also  to  the  access  lines  and  terminals.  This 
goal  must  necessarily  be  subjected  to  continual  critical 
review  to  ensure  the  state-of-the-art  will  permit  attaining 
and  maintaining  such  an  ideal  at  a  reasonable  cost. 

4 .  Improve  System  Responsiveness  to  Data  Users.  AUTODIN 
II  should  provide  the  data  user  with  a  backbone  system 
responsive  to  his  needs  for  interactive  communications.  In 
some  cases,  however,  the  data  processing  installation  (DPI) 
and  the  telecommunications  center  serving  it  have  developed 
a  relationship  in  which  some  functions  of  the  DPI  are 
shared  by  the  telecommunications  processor.  In  these  cases, 
AUTODIN  II  may  not  be  able  to  supplant  the  existing  AUTODIN 
I  terminal.  Development  of  a  common  user  solution  should 
encourage  such  users  to  reestablish  DPI  independence. 
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a.  Scheduled  Delivery  of  incoming  Data  Traffic. 

Since  most  DPIs  schedule  CPU  time  on  a  24  hour  basis, 
provisions  must  be  made  for  delayed  or  scheduled  delivery 
of  incoming  data  messages.  Store  and  forward  telecommuni¬ 
cations  systems  can  accommodate  this  service  at  any  point 
where  bulk  storage  capacity  exists.  A  packet  switching 
network  cannot  store  data  in  this  manner;  if  the 
requirement  for  scheduled  delivery  persists,  provisions 
for  intransit  storage  must  be  considered  in  the  IASA. 

b.  Preprocessing  of  Magnetic  Tape  Traffic.  In 
conjunction  with  scheduling  and/or  delaying  delivery  of 
data  traffic,  a  requirement  exists  to  sort  incoming  magnetic 
tape  traffic  to  permit  immediate  delivery  of  high  precedence 
messages.  Sorts  by  content  indicator  code  are  also 
required  in  some  cases  to  permit  the  delivery  of  tapes  or 
messages  (i.e. ,  logistics,  administrative,  etc.)  at 
different  times.  In  a  packet  switching  network  without 

the  assistance  of  a  store  and  forward  facility,  this  type 
of  service  cannot  be  provided  except  at  the  data  source. 

The  validity  of  the  requirement  as  well  as  the  means  to 
meet  it  must  be  considered  in  the  IASA. 

5 .  Transparency  of  Information  Processed  Throughout 
the  IAS .  The  system  must  not  be  tied  exclusively  to  a 
specific  character  set  or  formats.  The  user  must  be  able 
to  introduce  any  data  into  the  system  with  only  a  minimal 
amount  of  identification  and  accounting  information.  The 
specific  form  of  the  entered  data  must  be  unrestricted  and 
available  to  the  user  at  the  system  destination  in  a  form 
identical  to  its  originated  form.  Interaction  between  the 
system  and  the  data  should  not  be  discernible  by  the  user. 

6.  Standardization.  The  IASA  design  goal  of  a  terminal 
to  terminal  system  will  require  broad  range  standardization 
if  all  economies  are  to  be  realized.  Standardization  of 
telecommunications  procedures  such  as  precedence  handling, 
message  forms,  addressing  and  routing  and  staffing  is 
essential  to  interservice  operability;  once  procedures  are 
standardized,  further  standardization  and  subsequent  savings 
will  be  possible  in  the  several  areas  discussed  below.  A 

word  of  caution  is,  however,  in  order.  Although  standardization 
offers  considerable  promise  in  the  reduction  of  costs  and  in 
increased  interoperability,  it  is  not  a  panacea.  In  fact, 
standardization  must  be  carefully  controlled  to  ensure 
flexibility  is  maintained  as  a  design  objective.  The  IASA 
must  possess  sufficient  flexibility  to  meet  changing  user 
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requirements,  and  to  incorporate  new  technology  and 
techniques  afforded  by  the  continually  advancing  state- 
of-the-art.  The  two  goals  of  flexibility  and  standard¬ 
ization  are  not,  however,  incompatible.  For  example,  such 
mechanics  as  functional  specifications,  rather  than 
specifications  incorporating  specific  implementations,  can 
provide  the  requisite  degree  of  standardization  without 
sacrificing  flexibility. 

a.  Software  Techniques.  Software  cannot  be 
completely  standardized  until  all  users  have  common  hardware, 
a  condition  which  may  be  neither  possible  nor  desirable. 

A  high  level,  machine  independent,  telecommunications  oriented 
computer  language  could,  however,  provide  some  standardization 
in  cases  where  assembly  language  is  not  required  to  meet  the 
necessary  throughput.  The  most  fertile  area  for  standardization 
is  in  software  techniques.  After  standardization  of 
procedures  is  accomplished,  there  is  little  barrier  to 
developing  a  common  telecommunications  software  language. 

b.  Software  Development/Maintenance  Facilities.  Army, 
Navy,  and  Air  Force  all  operate  major  software  development/ 
maintenance  facilities.  After  standardization  of  procedures 
and  software  techniques ,  the  consolidation  of  these  software 
facilities  is  a  logical  consideration  and  should  be  explored 

in  con junction  with  IASA  development. 

c.  Telecommunications  Equipment/Services  Procurement. 
Although  successful  centralized  procurements  have  occurred, 
procurements  of  this  type  often  fail  to  meet  the  specialized 
needs  of  the  Services/Agencies.  If  standardization  of 
procedures  and  software  can  be  achieved,  specialized  needs 
should  be  reduced  to  a  minor  consideration  enhancing  the 
probability  that  central  procurement  can  be  employed  for 

the  majority  of  requirements. 

d.  Crypto  Devices.  Economies  can  be  realized  by 
establishing  a  single  family  of  crypto  devices  for  use 
throughout  the  IAS.  These  savings  would  evolve  primarily 
in  the  areas  of  procurement  and  maintenance. 

e.  The  modes  of  operation  identified  as  AUTODIN  I 
Standards  have  become  accepted  industry-wide  and  have  become 
universal  descriptors  of  telecommunications  protocols.  Of  the 
five  modes,  only  three  (Mode  I,  Mode  II  and  Mode  V)  are  in 
common  use  today.  Also,  AUTODIN  II  has  introduced  a  new 

set  of  modes  which  are  not  related  to  AUTODIN  I  modes.  As 
the  IASA  is  developed,  a  comprehensive  set  of  AUTODIN  modes, 
including  Mode  I,  Mode  II,  Mode  V,  and  the  AUTODIN  II  modes 
should  be  developed,  clarified,  and  promulgated  as  IAS  standards. 
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7 .  Telecommunications  Functions  Expected  to  Increase 
in  Demand"!  Many  telecommunications  capabilities  exists 
within  the  current  state-of-the-art  which  are  not  now  fully 
exploited,  either  because  the  requirement  has  not  been  identi¬ 
fied,  or  because  current  DoD  systems  cannot  economically  per¬ 
form  them.  The  Integrated  AUTODIN  System  should  incorporate 
within  itself  the  capability  to  exploit  these  capabilities  to 
meet  expected  new  or  increased  requirements. 

a.  Teleconferencing  -  A  service  which  provides  a 
video  or  data  conferencing  mode.  The  purpose  of  the  service 
is  to  take  the  place  of  an  in-person  meeting  or  conference. 
Data  conferencing  service  is  less  of  a  departure  from  current 
services  and  the  video  mode  is  a  considerable  change  and 
could  have  enormous  impact  on  both  system  design,  cost, 
savings,  energy  consumption,  and  the  manner  in  which  business 
is  conducted.  Data  conferencing  could  be  conducted  on  a 
keyboard  CRT  display,  whereby  members  of  the  conference 
address  one  another.  Conference  traffic  can  be  held  at  a 
switch  node  while  a  conference  participant  is  away  from  his 
terminal.  Video  conferencing  is  envisioned  through  use  of 
multiple  cameras  which  are  aimed  and  activated  by  voice 
recognition. 

b.  Word  Processing  -  A  service  composed  of  features 
and  functions  which  aid  in  the  preparation  of  typed  material. 
The  service  interfaces  with  a  secretary  or  typist  via  a  low 
speed  terminal,  generally  a  CRT,  keyboard  device.  The  com¬ 
puter  aids  in  composition  by  providing  multiple  editing 
capabilities,  reformatting,  and  file  storage.  In  this  manner, 
corrections  are  easily  made  and  copies  obtained.  The  communi¬ 
cations  aspect  involves  the  coordination  of  the  document 
between  parties  remote  from  each  other  and  the  final  distribu¬ 
tion  of  the  document.  This  will  speed  the  delivery  of  the 
document  and  aid  in  the  transportation  of  classified  material. 

c.  Internetting  of  Data  Bases  and  Networks  -  The 
requirement  and  the  capability  to  interconnect  networks  and 
to  access  large  remote  data  bases  will  be  present  in  the 
near-term  IAS. 

d.  Facsimile  -  This  has  been  demonstrated  for  use  in 
AUTODIN  I.  AUTODIN  II  will  offer  a  more  effective  common- 
user  system  for  the  facsimile  user. 

D.  System  Requirements. 

1.  AUTODIN  I.  Statistics  over  the  last  two  years  reflect 
growth  rates  in  AUTODIN  I  of  approximately  3.4%  for  messages 
and  11%  for  lineblocks.  The  difference  in  growth  rates  is 


due  in  large  part  to  subscribers  processing  bulk  data  (magnetic 
tapes,  cards) .  Over  the  period  1975-1977  the  number  and 
distribution  of  AUTODIN  I  terminations  are  3s  follows: 

1975  1977 


CONUS 

840 

856 

Pacific 

232 

205 

Europe 

253 

261 

TOTAL 

1325 

1322 

With  the  projected  growth  in  AUTODIN  I  traffic  volume,  the 
trend  to  higher  speed  access  lines  will  be  watched  closely 
to  measure  the  impact  on  ASC  throughput.  A  further  analysis 
of  the  terminal  environment  is  provided  in  Section  III.D. 

2.  AUTODIN  II.  The  following  statistics  represent  the 
demand  for  AUTODIN  II  service  projected  out  to  1983: 

.  42  ADP  Systems 

.  156  hosts,  1262  terminals 

.  Busy  hour  traffic  of  19.13  x  10^  bits 
(exclusive  of  AUTODIN  I  traffic) 

In  addition  to  the  above  projections,  overseas  requirements  for 
AUTODIN  II  have  been  identified  for  Europe,  Pacific,  Alaska, 
and  the  Canal  Zone.  The  method  of  terminating  these  overseas 
requirements  will  be  multiplexing  to  a  CONUS  PSN. 

a.  The  European  area  requirements  for  AUTODIN  II  are 
for  26  terminations  with  in-service  dates  between  January  1979 
and  December  1981.  Of  these,  19  are  located  in  the  Federal 
Republic  of  Germany,  three  are  in  England,  two  are  in  Spain, 
and  one  each  in  Italy  and  Saudi  Arabia.  Line  speeds  for  these 
requirements  range  from  150  to  19.6  kilobaud.  An  alternative 
approach  is  presented  in  Section  III.B.,  whereby  a  PSN  would 
be  located  in  Pirmasens,  Germany  in  1981. 

b.  The  Pacific  area  requirements  for  AUTODIN  II  are 
for  16  terminations  with  in-service  dates  between  January  1979 
and  December  1981,  Of  these,  twelve  are  located  in  Hawaii  with 
one  each  located  at  Clark,  Philippine  Islands,  Kamiseya,  Japan, 
Guam,  Mariana  Isands,  and  Seoul,  Korea.  Line  speeds  for  these 
requirements  range  from  150  to  19.6  kilobaud.  An  alternative 
approach  is  presented  in  Section  III.B.,  whereby  a  PSN  would  be 
located  at  Wahiawa,  Hawaii  in  1981. 
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c.  The  Alaska  requirements  for  AUTODIN  II  are  for 
twelve  terminations  with  in-service  dates  between  January 
1979  and  December  1981.  All  are  located  in  the  Elmendorf/ 
Anchorage  area.  Line  speeds  for  these  requirements  range 
from  300  to  9600  baud. 

d.  There  is  one  Canal  Zone  WWMCCS  Intercomputer 
Network  (WIN)  termination  at  a  line  speed  of  9.6  kilobaud. 
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SECTION  III 


SYSTEM  ARCHITECTURE  (1978-1983) 


A.  Definition.  The  IAS  Architecture  is  a  system-level 
description  which  considers  all  the  user  motivated 
functions  (e.g.,  plain  language  addressing)  and  system- 
motivated  functions  (e.g.,  routing)  required  for  end-to- 
end  data  communications  and  teleprocessing  services, 
allocates  these  functions  to  a  feasible  subset  of  the 
set  of  all  possible  elements  (e.g.,  nodes,  multiplexers, 
terminals,  etc) ,  partitions  the  elements  into  levels 
(i.e.,  backbone,  local  and  regional  access  area),  specifies 
the  transmission  media  and  connectivity  policy  for 
interconnecting  the  various  elements  and  network  levels,  and 
describes  the  method  of  system  operation.  In  doing  so, 
hardware  and  software  features  will  be  included,  and  the 
way  in  which  the  elements  are  interconnected  into  a 
network  topological  structure  will  be  specified.  All 
protocols,  interfaces,  routing  methods,  and  other 
operational  and  control  procedures  which  determine  how  the 
interconnection  and  operation  of  elements  provide  the 
required  service  to  the  user  will  be  stipulated. 

The  IAS  Architecture  will  be  comprehensive  enough  to 
allow  the  development  of  requisite  functional  specifications 
and  to  allow  for  meaningful  costing  at  the  system  level. 

For  those  elements  which  already  exist  or  are  already 
designed,  engineering  and  software  documentation  or 
specifications  and  planning  documents  will  be  incorporated 
into  the  architectural  description.  For  new  elements, 
functional  specifications  must  be  developed  to  complete 
the  description. 

The  IAS  Architecture  will  establish  the  necessary  elements 
for  the  orderly  growth  of  DoD  data  communications,  and  provide 
decision  makers  with  the  requisite  criteria,  in  terms  of 
planning  and  costing  data,  to  make  accurate,  timely  and 
meaningful  decisions.  Decisions  predicated  on  the  IAS 
Architecture  will  be  founded  upon  a  total  terminal-to-terminal 
system  design,  eliminating  functional  duplication  and  enabling 
a  cost-effective  approach  to  the  acquisition  of  needed 
communications  capability.  The  approved  IAS  Architecture 
will  be  the  basis  from  which  the  detail  design  can  begin. 
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Designers  will  use  the  IAS  Architecture  as  technical  and 
policy  guidance  to  prepare  development  plans  for  obtaining 
the  hardware  and  software  needed  to  advance  from  the  1978- 
1983  architecture  to  the  mature  architecture  of  the  future. 

The  purpose  of  this  section  is  to  provide  near-term  imple¬ 
mentation  alternatives  and  recommendations  for  major  network 
elements  to  include  backbone  switches,  access  area  exchanges 
and  terminals.  Figure  3  illustrates  the  near-term  architec¬ 
ture  which  consists  of  the  Backbone  and  Access  Area  (Regional 
and  Local) . 

B.  Backbone  Switches. 

1.  AUTODIN  I.  The  Automatic  Digital  Network  (AUTODIN) 

I  is  a  store  and  forward  switched  network  of  the  Defense 
Communications  System  (DCS)  which  functions  as  a  single  inte¬ 
grated  worldwide,  high-speed,  computer-controlled,  general- 
purpose  communications  network,  providing  secure  record  com¬ 
munications  service  to  the  Department  of  Defense  (DoD)  and 
other  Federal  agencies.  Figure  4  shows  a  worldwide  layout 
of  the  17  AUTODIN  Switching  Centers.  AUTODIN  I  has  been 
operational  for  approximately  15  years  and  has  undergone 
numerous  enhancements  and  expansions  to  meet  the  growing  re¬ 
quirements  for  data/record  communications.  In  addition,  there 
are  many  enhancements  and  improvements  in  process  and/or 
planned  for  the  AUTODIN  I  to  keep  it  viable  and  responsive  to 
the  needs  for  data/record  communications  into  the  1980s. 

a.  CONUS .  An  expanded  memory  system  has  recently 
been  installed  at  the  eight  CONUS  and  one  Hawaii  switching  centers 
because  it  was  determined  that  these  ASCs  would  have  been  out 
of  core  following  the  next  major  assembly.  The  expanded 
memory  system,  which  consists  of  four  disc  units  and  two  mini¬ 
computers  at  each  switch,  frees  up  core  space  necessary  for 
additional  programs,  provides  faster  cycle  time  than  the  old 
mass  memory  units,  and  the  new  software  package  will  allow  for 
a  larger  operating  program  through  program  overlays.  Another 
CONUS  AUTODIN  support  project  is  replacement  of  the  magnetic 
tape  and  mass  memory  units  with  disc  units  at  each  ASC.  In 
addition  to  a  $4  million  cost  savings  over  an  eight  year  life, 
this  enhancement  will  provide  the  needed  direct,  high-speed, 
channel  interconnect  to  the  AUTODIN  II  PSNs. 
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Footnotes 

1.  Immediately  prior  to  1980  and  for  a  period  following,  the 
access  area  nodes  will  be  some  form  of  AMPE. 

2.  Access  area  nodes  can  be  terminated  on  either  ASCs  or  PSNs 
and  overseas  ASCs  will  be  trunked  to  CONUS  ASCs. 


Figure  3-  Continued 
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b.  Overseas.  To  meet  current  forecasted  operational 
requirements  and  to  replace/refurbish  worn  out  subsystems 
of  Overseas  AUTODIN  I,  DCA  has  initiated  several  replacement 
projects.  They  are  memory /memory  control  replacement  program; 
input/output  controller,  card  reader,  and  high-speed  printer 
replacement;  tape  subsystem  replacement;  patch  and  test  facility 
upgrade;  NATO  TARE  interconnection,  and  minor  system  engineering 
modifications.  These  enhancements  will  insure  operation  of  the 
overseas  AUTODIN  through  at  least  1985. 

2.  AUTODI N  II.  The  AUTODIN  II  is  a  general  purpose  data 
communications  packet  switched  network  for  integrating  the 
teleprocessing  and  record  communications  needs  of  DoD  into  a 
single  digital  backbone  system. 

a.  CONUS.  AUTODIN  II  Phase  I  has  an  Initial 
Operational  Capability  (IOC)  of  FY  1979  to  include  four  Pais 
with  options  for  four  or  more  additional  PSNs. 

(1)  Network  Characteristics. 

(a)  The  design  of  the  AUTODIN  II  Phase  I 
system  is  based  on  packet-switching  technology  with  the 
intent  to  use  fully  those  aspects  of  the  ARPANET  design 
technology,  such  as  proven  algorithms,  that  are  applicable 

to  the  new  system.  The  system  will  employ  a  short  data  handling 
unit,  or  packet  of  bits,  to  accommodate  man-computer,  computer- 
computer  and/or  computer- terminal  data  traffic. 

(b )  Each  packet  switch  will  perform  the 
following  basic  functions:  route  and  distribute  packetized 
traffic  (interactive,  query-response,  record,  and  bulk-data) 
over  a  full  duplex  wide-band  trunking  network;  electrically 
interface  with  the  AUTODIN  I  system  through  CONUS  ASC's; 
terminate  up  to  150  lines  (both  individual  and  multiplex  )  per 
switch  with  a  capability  to  service  up  to  several  hundred  data 
subscribers;  and  accommodate  dial-up  access  lines  for  low 
volume  subscribers  and  emergency  restoration. 

(c  )  The  initial  network  will  consist  of 
three  PSNs  at  Ft.  Detrick,  Tinker  AFB,  and  McClellan  AFB  with  a 
Network  Control  Center  at  Headquarters  DCA.  The  acceptance 
of  this  three  node  network  establishes  a  FY  1979  IOC.  Two 
months  later,  a  fourth  PSN  will  be  added  at  Gentile  AFB. 
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The  growth  of  the  network  from  that  point  will  depend  on  user 
requirements  and  the  dates  they  can  provide  the  necessary 
software  and  hardware  interfaces  to  connect  to  the  network. 

It  is  envisioned  that  the  network  service  will  grow  incre¬ 
mentally,  as  required,  to  meet  additional  requirements. 

(2)  Network  Access. 

(a)  There  are  two  basic  types  of  subscribers 
to  the  AUTODIN  II:  network  hosts  and  terminals.  Hosts  are 
computers  which  are  capable  of  simultaneously  conducting 
multiple  conversations  with  other  hosts  or  terminals.  Host 
computers,  in  general,  are  the  centers  of  major  ADP  telepro¬ 
cessing  systems  and  are  major  sources  of  network  traffic. 

(b)  Terminals  are  defined  as  either  bit  or 
character  oriented  devices  capable  of  conducting  a  conver¬ 
sation  with  only  one  destination  at  a  time.  Terminals  input 
to  the-  packet  switching  network  interactive  (I/A) ,  query/ 
response  (Q/R) ,  bulk,  or  narrative  type  applications.  Terminal 
devices  may  be  computer  peripheral  controllers  and  intelligent 
or  unintelligent  input/output  devices.  The  PSN  will  interface 
with  terminals  so  as  to  minimize  the  hardware  and  software 
impacts  on  these  users.  Multiplexers  are  used  extensively  in 
this  network  to  minimize  the  cost  for  access  lines. 

(3)  Data  Flow.  In  this  typical  network  data  flow, 
the  traffic  source  (computer,  terminal,  or  AUTODIN  II)  will 
present  a  data  segment  to  the  source  PSN.  The  source  node  will 
accept  traffic  a  segment  or  character  at  a  time  from  a  sub¬ 
scriber,  make  prescribed  control,  security  and  community  of 
interest  checks,  format  the  segment  into  a  packet  for  network 
transmission  and  send  each  packet  separately  into  the  network 
on  the  appropriate  trunk.  Intervening  nodes  would  relay  the 
packets.  The  destination  node  will  reform  each  packet  into 
subscriber  deliverable  traffic  in  the  form  of  a  segment, 
perform  outgoing  validation  checks,  deliver  the  segment  or 
characters  to  the  destination  terminal  and  acknowledge  receipt. 
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(4)  Privacy  and  Security.  One-half  of  the  ADP 
users  have  a  requirement  to  transfer  information  which  may 
be  sensitive  in  terms  of  national  security  and/or  proprietary 
in  nature  (to  the  user  community) .  To  meet  this  need,  the 
AUTODIN  II  Phase  I  system  link  and  switch  facilities  will 
be  secured  to  the  highest  classification  level  transmitted, 
and  will  be  capable  of  being  compartmented  by  use  of 
transmission  control  codes  (TCC)  and  virtual  logical  channels. 
Each  data  packet  will  be  verified  as  to  the  authorized 
security  level  and  community-of-interest  of  both  the  sender 
and  receiver. 

b.  Overseas.  AUTODIN  II  Phase  II  is  defined  as 
the  overseas  portion  of  the  PSN  implementation  scheme.  An 
IOC  of  FY19.83  has  been  identified  in  the  DCS  Five  Year 
Program  (FYP)  1980  for  providing  additional  PSNs  on  a 
worldwide  basis.  Under  this  concept,  in  the  1980  time  ■'  frame 
multiplexers  would  be  located  overseas  to  reduce  access 
line  costs,  and  as  new  requirements  are  identified,  PSNs 
would  be  located  overseas.  An  alternative  approach  to 
multiplexing  is  to  install  PSNs  overseas  in  the  1981  time 
frame.  Further  discussion  on  these  alternative  is  provided 
in  this  Section  under  the  sub-heading  Implementation 
Alternatives. 

3.  AUTODIN  I/II  Relationships. 

a.  Roles.  The  need  for  record/narrative  message 
services  provided  by  AUTODIN  I  is  expected  to  remain  stable 
through  the  implementation  period  of  AUTODIN  II  Phase  I. 
AUTODIN  I  will  use  the  packet-switched  backbone  system 
established  in  AUTODIN  II  Phase  I  for  all  CONUS  trunk 
transmissions.  The  current  interface  of  the  overseas 
AUTODIN  I  network  will  be  through  current  CONUS  AUTODIN  I 
ASC’s.  AUTODIN  T  service  will  be  enhanced  by  the  inherent 
speed  and  interoperability  capabilities  provided  by  the 
AUTODIN  II  transmission  system;  however,  AUTODIN  II  will  be 
transparent  to  current  AW. ODIN  I  user  procedures  and 
formats.  Prior  to  cutover  of  AUTODIN  '  traffic  and 
deactivation  of  existing  AUTODIN  I  trunking,  the  packet 
switched  system  will  bo  fully  verified  by  operational 
testing  to  insure  that  the  traffic  of  both  A'JTODIN  I  and 
the  packet  switch  subscribers  are  not  impacted  by  use  of 
common  trunking. 
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b.  Comparison.  The  similarities  and  differences 
between  AUTODIN  I  and  AUTODIN  II  are  summarized  in  Table  1. 

(1)  AUTODIN  II  features  a  higher  bandwidth  for 
trunks  and  (selectively)  higher  bandwidth  for  access  circuits. 
The  small  packet  size  permits  low  delay  and  high  throughput 
characteristics.  The  low  delay  characteristic  permits  much 
better  Q/R  service,  since  the  queueing  delays  at  the  switch 
node  are  sharply  reduced.  The  higher  bandwidth  permits  high 
throughput  for  bulk  traffic,  including  computer  communications. 

(2)  Some  features  of  AUTODIN  I  are  not  accomplished 
in  AUTODIN  II,  since  the  Packet  Switch  Nodes  (PSN)  of  AUTODIN 

II  do  not  provide  for  storage  of  messages.  No  record  is 
maintained  of  traffic  handled  as  this  becomes  a  user 
responsibility.  In  addition,  the  PSN  does  not  provide  the 
capability  of  handling  multiple/collective  addresses 
accomplished  in  AUTODIN  I. 

4.  Implementation  Alternatives.  In  order  to  satisfy 
the  user  demands  for  service  and  to  insure  a  level  of  spare 
capacity  to  meet  contingencies  and  survivability  at  a  level 
equal  to  today's  requirements,  an  analysis  of  alternatives 
is  provided  of  the  number  and  location  of  AUTODIN  I  ASCs 
and  AUTODIN  II  PSNs.  The  backbone  switches  are  analyzed 
by  CONUS  and  overseas  applications.  To  reduce  the  repetitive 
analysis  of  similar  items  within  the  three  alternatives 
presented,  the  approach  is  to  evaluate  each  item  only  once  and 
then  refer  to  this  item  analysis  within  the  other  alternatives. 
Three  potential  networks  are  postulated  and  examined  as 
implementation  alternatives. 

a.  Alternative  1.  Four  PSNs/eiqht  ASCs  in  CONUS; 
three  ASCs  in  Europe;  five  ASCs  in  the  Pacific.  The  inter¬ 
connection  of  this  network  is  postulated  in  Figure  5. 

(1)  CONUS.  Four  PSNs  will  be  the  initial 
operational  capability  of  AUTODIN  II,  Phase  I  and  these 
are  planned  to  be  in  operation  in  1979.  An  additional 
four  PSNs  are  approved  for  implementation,  if  requirements 
for  them  exist.  This  particular  configuration  alternative 
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TABLE  1 


AUTODIN  I /I I 

FUNCTIONAL  COMPARISON 

CHARACTERISTICS 

AUTODIN  I 

AUTODIN  II 

Common  User  System 

Yes 

Yes 

Store-and- Forward 

Yes 

No 

Packet  Switch 

No 

Yes 

Modes  of  Operation 

3 

4 

Message  Accountability 

ASC 

User 

Precedence  Processing 

Yes 

Yes 

Security  Classifications 
Processing 

Yes 

Yes 

Journaling 

Yes 

No 

Format  &  Code  Conversion 

Yes 

Limited 

Multiple  &  Collective 
Addressing 

Yes 

No 

Dual  Homing 

Yes 

Yes 

Interactive 

No 

Yes 

Query /Response 

Limited 

% 

Yes 

Bulk  Traffic 

Yes 

Yes 

Guaranteed  Sequential 

Delivery 

Yes 

No 

Facsimile 

Yes 

Yes 

Privacy 

Yes 

Yes 

Language  Media 

Data 

Yes 

Yes 

Narrative 

Yes 

Yes 

Message  Integrity 

Yes 

Yes 

Message  Integrity 
Standards  for  Reliability 


99.5% 


99.95% 


TABLE  1  (CONTINUED) 


CHARACTERISTICS 

AUTODIN  I 

AUTODIN  II 

Error  Control 

Block  Parity  and 
Retransmission 

FIPS  Algorithm 
(32  bit  CRC) 

Access  Lines/Switch 

250  max 

150  max 

Manning  Overhead 

100/switch 

10/switch  with 
existing  ASC 

Storage 

Full  Message 

Packet 

Processing  Speed  LBs/Sec 

250 

744 

Bandwidth  Limitations  - 
Access  Lines 

4800  bps 

56,000  bps 

Routing  Techniques 

Deterministic 

Adaptive 

Inherent  Delays 

Minutes 

Seconds 

Buffering 

Full  Message 

Packet 

Message  Lengths  (max) 

500  lineblocks 

625  char/packet 

Types  of  Subscribers-Mode 

1 1  II,  v 

I,  IB,  IIA,  VI 

Transmission  Media  -  Trunks 

4800  bps 

230,000  bps 

Network  Control 

NCC/MILDEPs 

NCC 

Vulnerability/Survivability 

8  CONUS 

4-8  CONUS 

Encryption  Scheme 

Link 

Link 
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speculates  that  either  the  requirements  for  additional 
PSNs  will  not  materialize,  the  funding  will  be  withheld, 
or  some  other  unforeseen  occurrence  will  happen  such  that 
the  system  maintains  only  the  four  initial  PSNs.  The 
locations  for  these  nodes  have  been  specified  as 
Ft.  Detrick,  Tinker  AFB ,  McClellan  AFB,  and  Gentile  AFB. 

The  eight  ASCs  shown  in  Figure  5  currently  exist  and 
would  remain  as  configured* 

(2)  Europe.  Figure  4  shows  the  configuration 
of  the  three  ASCs  in  Europe  today.  The  first  alternate 
configuration  (Figure  5)  for  the  1983  IAS  shows  the 

same  three  ASCs  with  enhanced  trunks  between  the  European 
ASCs  and  between  Europe  and  the  CONUS.  This  is  due  to  the 
near  term  increase  in  requirements  for  4800  baud 
terminations  in  Europe .  The  present  day  use  of 
the  European  trunks  is  high  and  it  is  planned  to  use  a 
biplexed  9600  bps  modem  to  provide  dual  4800  bps  service 
where  required. 

(3)  Pacific.  The  current  Pacific  configuration 
is  shown  in  Figure  4 .  Figure  5  shows  the  IAS  configuration 
for  circa  1983  and  reflects  that  the  Buckner  ASC  will  be 
placed  in  caretaker  status  by  15  January  1978  and  the 

Camp  Drake  ASC  will  be  relocated  within  Japan. 

This  relocation  is  being  accomplished  to  achieve  a  lower 
overall  O&M  expense.  Alternative  1,  Figure  5,  envisions 
a  set  of  requirements  that  remain  fairly  constant  or 
increase  slightly.  The  Pacific  is  somewhat  unique  in  that 
the  ASCs  are  to  the  greater  extent  servers  of  in-country 
needs  for  subscriber  terminals.  As  such,  political/ 
military  decisions  with  regard  to  our  presence  in  a 
particular  territory  dictate  both  the  presence  of  the 
subscriber  terminals  and  the  ASC.  Removal  of  an  ASC 
without  removal  of  the  subscriber  terminals  could  place 
a  burden  on  the  inter-country  transmission  facilities. 

The  cost  of  transmission  in  the  Pacific  is  high  due  to 
the  current  cost  being  proportionate  to  distance.  The 
availability  of  transmission  facilities  also  is  a  problem 
in  part  of  the  Pacific.  The  requirements  are  generally 
met  by  high  efficiency  multiplexers  when  subscriber  access 
lines  are  extended  inter-country.  A  study  is  underway  which 
will  determine  how  the  AUTODIN  will  serve  CINCPAC  in  the 
near  term.  The  results  of  this  study  will  be  available  in 
May  1978. 
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b.  Alternative  2.  Eight  PSNs/four  ASCs  in  CONUS; 
three  ASCs  in  Europe;  four  ASCs  in  the  Pacific.  Figure  6 
depicts  an  alternate  IAS  configuration  for  the  1983  time 
frame.  It  features  completion  of  the  eight  node  AUTODIN  II 
Phase  I  packet  switching  network  in  CONUS.  In  addition,  it 
postulates  that  four  of  the  eight  ASCs  in  CONUS  have  been 
closed  as  projected  in  the  AUTODIN  II  DCA  Business  Plan. 

The  European  configuration  is  identical  to  the  first 
alternative.  The  Pacific  configuration  shows  the  closure 
of  an  additional  ASC.  For  planning  purposes,  the  Taegu  ASC 
is  projected  as  closed;  however,  the  pending  results  of  the 
Pacific  reconfiguration  study  may  alter  the  ASC  closure  selection. 

(1)  CONUS.  Figure  6  depicts  the  Andrews,  Hancock, 
Norton,  and  Albany  ASCs  as  closed.  The  DCA  AUTODIN  II 
Business  Plan  projected  the  closure  of  Hancock,  Albany, 

Tinker,  and  Gentile  ASCs;  however,  the  above  closures  are 
more  logical  because  the  remaining  ASCs  provide  better 
geographic  coverage.  Only  the  low  speed  circuit  miles  are 
affected  by  the  choice  of  which  set  of  ASCs  are  closed,  and 
these  differences  can  be  reduced  by  employing  Time  Division 
Multiplexers. 


(a)  Factors  Affecting  ASC  Closures. 
Requirements  in  terms  of  the  number  of  subscriber  connections 
needed,  total  traffic  in  the  busy  period,  and  the  Services 
and  Agencies  plans  for  use  of  AMPEs  are  important  factors 
affecting  the  required  collective  capabilities  of  the  ASCs. 
The  ability  of  the  individual  ASCs  to  terminate  subscribers, 
the  capacity  of  AUTODIN  I/AUTODIN  II  interface,  and  the 
throughput  capabilities  required  to  handle  the  traffic  are 
the  major  technical  constraints  on  closing  ASCs.  The 
economic  factors  involved  are  the  costs  savings  realized 

by  closing  an  ASC,  including  leased  cost,  personnel  savings, 
and  base  support  costs. 

(b)  Integration  of  ASCs  and  PSNs.  At  a 
collocated  ASC/PSN  facility  any  integrated  patch  and  test 
operation  will  be  implemented  with  management/administrative 
and  crypto  maintenance  functions  absorbed  by  the  current  ASC 
personnel.  An  additional  ten  personnel,  will  be  provided 
for  operation  of  the  PSN  on  a  24  hour  basis.  The  closure  of 
AUTODIN  I  ASCs  is  dependent  upon  how  effectively  the  inter¬ 
face  to  the  AUTODIN  II  PSNs  is  implemented. 

1.  Contract  negotiations  to  make 
changes  in  the  AUTODIN  I  ASCs  to  allow  for  a  high  speed 
interconnection  to  AUTODIN  II  are  in  progress.  The  ability 
to  bypass  the  Accumulation  Distribution  Unit  (ADU)  is 
critical  to  the  ability  to  close  ASCs.  Currently  the  number 
of  subscribers  that  can  be  terminated  on  an  ADU  is  limited 
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by  the  capacity  of  the  Data  Memory.  The  amount  of  memory 
used  per  subscriber  varies  with  speed.  A  2400  or  4800 
bps  trunk  or  tributary  requires  28  lineblocks  of  storage; 
a  low  speed  tributary  requires  6  lineblocks .  The  data 
memory  CONUS  wide  is  currently  75%  used.  It  can  be 
observed  that  if  half  the  ASCs  were  closed,  the  remaining 
ASCs  Data  Memory  would  be  50%  oversubscribed.  With  the 
advent  of  a  suitable  direct  interface  between  AUTODIN 
I  and  II,  this  limitation  can  be  overcome.  Current 
proposals  call  for  interfacing  via  dual  56  kbps  duplex 
serial  communications  channels,  operating  in  Mode  VI 
(i.e.,  the  proposed  ADCCP  standard).  This  interface  will 
terminate  in  the  AUTODIN  I  PDP11/34  ,  which  was  added  to 
AUTODIN  I  CONUS  to  facilitate  mass  storage  requirements. 

2.  A  limitation  on  an  ASC's  ability 
to  terminate  more  subscribers  is  in  the  ability  of  the  ASC 
to  throughput  the  traffic.  Throughput  is  a  capability 
which  is  affected  by  a  seemingly  unlimited  number  of 
variables,  therefore,  the  throughput  ability  changes  with 
every  program  improvement  and  its  exact  value  is  unknown. 

A  network  simulation  of  four  ASCs  in  CONUS  was  analyzed  to 
determine  the  maximum  throughput  that  would  be  required  of 
an  ASC.  The  ability  of  an  ASC  to  throughput  is  a  critical 
factor  to  reduce  the  number  of  CONUS  ASCs  from  eight  to 
four.  The  simulation  used  current  traffic  loads.  The  peak 
demand  was  experienced  at  the  Fort  Detrick  ASC  for  which 
there  was  an  average  of  217  line  blocks  per  second  (lb/s) 
over  a  15  second  period.  The  other  three  ASCs  experience 
peaks  of  213,  215  and  174  lb/s.  In  that  the  ability  of  an 
ASC  to  throughput  data  is  estimated  at  200  lb/s  +  50  lbs, 
the  ability  of  a  four  ASC  network  is  in  question. 

(c)  Cost.  The  DCA  Business  Plan  for 
AUTODIN  II  Phase  I  contemplated  the  closure  of  Hancock, 

Albany,  Tinker,  and  Gentile  ASCs.  In  the  simulation  and 
rehoming  plan  developed  for  the  four  switch  closure  study, 
the  Tinker  and  Gentile  ASCs  were  retained  and  Andrews  and 
Norton  ASCs  replaced  them.  Refer  to  Table  2  for  the  estimated 
AUTODIN  I  Switch  Closure  Savings. 
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TABLE  2 


AUTODIN  I  SWITCH  CLOSURE  SAVINGS 


(TABLE  DELETED) 


(3)  Approach.  The  approach  to  implementing 
this  alternative  is  to  reterminate  AUTODIN  I  subscribers  which 
are  Mode  I  to  a  PSN  and  use  the  packet  network  to  extend  the 
termination  to  a  distant  ASC  via  its  collocated  PSN  to  achieve 
a  home  ASC  for  subscribers.  Reference  is  made  to  Table  3. 

1.  A  data  base  was  prepared  which 
contained  all  the  present  AUTODIN  I  subscribers ,  their 
coordinates,  speed,  present  ASC  and  dual  homed  pair  identity 
if  they  had  one.  The  data  base  was  updated  with  recent  data 
from  the  Agencies  and  MILDEPs  to  include  their  projected  AMPE 
connectivity  to  the  ASCs  and  the  current  ASC  subscribers 
that  will  be  moved  (projected  at  127)  to  the  backside  of  AMPEs 
by  1980.  The  validity  of  the  data  base  was  tested  against  the 
AUTODIN  Monthly  Summaries. 


2.  With  data  base  the  distance  from 
each  subscriber  location  to  the  nearest  ASC  or  PSN  was 
determined.  Each  subscriber  was  then  placed  on  an  ASC  or 
PSN  in  the  four  ASC,  eight  PSN  configuration.  All  the  low 
speed  subscribers  were  placed  first;  the  45  and  75  baud 
subscribers  were  placed  on  the  nearest  ASC.  The  amount  of 
data  memory  being  committed  for  each  tributary  was  recorded 
in  the  event  the  ASC  became  over  subscribed.  The  difference 
between  current  homing  and  proposed  homing  in  terms  of  access 
circuit  miles  was  also  computed.  The  placement  was  completed 
without  over  subscribing  any  ASC.  The  subscribers  who  were 
placed  on  the  PSNs  were  not  assigned  a  home  ASC.  This 
remained  to  be  done  manually.  In  cases  where  dual-homed 
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subscribers  were  encountered,  the  algorithm  placed  them  on 
the  two  nearest  facilities.  Based  on  this  analysis,  there 
were  51  less  subscribers  present  in  the  network.  This  is 
the  net  loss  due  to  movement  of  tributaries  to  the  backside 
of  AMPEs  and  the  addition  of  AMPEs  as  tributaries  of  the  ASCs. 
The  Andrews,  Norton,  Albany,  and  Hancock  facilities  are  PSNs 
and  as  such  have  less  subscribers  because  they  have  no  45 
and  75  baud  tributaries.  If  this  was  not  recognized,  the 
conclusion  could  be  reached  that  they  are  without  doubt 
the  least  used  facilities. 

(e)  Timing  of  ASC  Closures.  Alternative 
2  describes  the  network  after  eight  PSNs  have  been 
installed  and  four  of  the  original  eight  ASCs  have  been 
closed.  To  transition  from  the  current  AUTODIN  config¬ 
uration  to  the  Alternative  2  approach,  the  recommended 
method  is  to  install  the  four  initial  PSNs,  test  them 
out  operationally,  and  then  close  one  ASC.  Then,  as  each 
additional  PSN  (fifth  through  seventh)  is  installed  the 
collocated  ASC  would  be  closed.  This  incremental  ASC 
closure  scheme  will  provide  sufficient  opportunity  to 
check  out  the  throughput  capability  on  the  remaining 
ASCs  without  adversely  impacting  the  user  service. 

For  the  latter  three  ASC  closures,  the  AUTODIN  I  Mode  I 
subscribers  would  be  connected  to  the  PSN  (using  the  same 
access  lines)  and  the  PSN  network  would  home  them  to  one 
of  the  remaining  ASCs.  The  integrated  network  would 
contain  no  less  than  eleven  switches  at  any  one  time  and 
in  the  final  configuration,  the  original  eight  CONUS 
locations  would  have  switches.  Maintenance  of  this  number 
of  nodes  is  important  to  the  survivability  of  the  network. 
Because  the  access  lines  are  not  disturbed,  little  or  no 
change  is  felt  by  the  Mode  I  subscribers  and  costs  for 
their  access  lines  remain  constant,  if  expansion  from 
the  four  node  PSN  network  to  the  eight  node  network  proceeds 
slowly  (awaiting  requirements  or  money)  it  would  be  unwise 
and  of  suspect  profitability  to  close  additional  ASCs  until 
PSNs  are  installed.  Not  only  would  the  availability  be 
lessened,  but  because  the  facility  would  not  have  a 
collocated  PSN,  its  tributaries  would  require  new  and 
longer  access  lines  (at  additional  cost  to  the  Services 
and  Agencies) .  This  situation  would  persist  until  a 
PSN  was  installed  at  the  former  ASC  facility.  While  some 
cost  benefit  could  be  attributed  to  installing  a  PSN 
in  a  facility  after  an  ASC  has  been  closed,  these  savings  are 
not  so  great  as  to  outweigh  the  operational  upheaval  multiple 
access  line  reconfiguration  would  cause  the  subscribers. 
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TABLE 


(2)  Overseas.  The  European  configuration  is 
the  same  as  the  current  configuration,  namely,  ASCs  at 
Croughton,  Pirmasens,  and  Coltano,  with  some  minor  exceptions 
on  transatlantic  trunk  speeds.  Pacific  onfiguration  shows 
the  closure  of  an  additional  ASC  with  remaining  ASCs  in 
Japan,  Guam,  Philippines,  and  Hawaii.  AUTODIN  II  overseas 
requirements  would  be  served  with  the  CONUS  based  Phase  I 
system.  Multiplexers  would  be  located  overseas  to  reduce 
access  line  costs.  Then  as  requirements  increase,  PSNs 
would  be  located  overseas. 

c.  Alternative  3.  Eight  PSNs/four  ASCs  in  the  CONUS; 
three  ASCs/one  PSN  in  Europe;  four  ASCs/one  PSN  in  the 
Pacific. 


(1)  CONUS.  Alternative  2  discusses  the  eight 
AUTODIN  II  Phase  I  PSNs  in  CONUS;  in  addition,  it  postulates 
the  closure  of  up  to  four  ASCs  in  CONUS.  Since  the  CONUS 
configuration  remains  the  same,  only  the  overseas  PSN 
alternative  will  be  discussed  herein. 

(2)  Overseas.  There  are  several  viable  options 
or  alternatives  for  implementation  of  AUTODIN  II  packet  switch¬ 
ing  overseas,  both  from  a  method,  as  well  as  a  location 

point  of  view.  Prior  to  analysis  of  the  various  methods 
of  extension,  a  brief  analysis  of  locations  is  in  order. 

Figure  7  shows  that  overseas  PSN  implementations  are 
collocated  with  AUTODIN  ASCs  as  in  AUTODIN  II  CONUS.  Further, 

the  collocations  are  shown  at  the  Pirmasens __ ASC  in  Germany, 
and  the  Wahiawa  ASC  in  Hawaii.  Survivability  considerations  must 
be  evaluated  in  the  determination  of  final  site  locations. 
Locations  of  the  PSNs  collocated  with  the  ASCs  presents  a  question 
in  the  survivability  area,  i.e.,  "all  the  eggs  in  one  basket." 

With  the  basic  site  locations  recommended,  it  is  now  possible 
to  postulate  alternatives  for  implementation.  The  initial 
extension  of  AUTODIN  II  overseas  in  envisioned  as  being  a 
small  or  reduced  representation  of  th  full  scale  capability. 

A  full  scale  AUTODIN  II  PSN  is  capable  of  handling  from  50  up  to 
150  terminations,  consisting  of  either  individual  or  multiplexed 
lines.  Overseas  requirements,  as  discussed  in  Section  II,  are 
reduced  from  this  capability.  Accordingly,  the  overseas 
implementation  would  be  of  the  small  type  configuration.  Figure  7 
postulates  European  and  Pacific  implementation  configurations 
with  an  eight  PSN  CONUS  network.  Both  overseas  PSNs  would  be 
homed  on  two  CONUS  PSNs,  and  the  collocated  ASC  could  derive  its 
CONUS  connectivity  through  the  PSN.  With  a  reduced  PSN 
implementation,  trunking  from  the  overseas  PSNs  would  be  a 
packet  trunk  to  a  PSN  and  a  Mode  I  trunk  to  an  ASC. 
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IAS  CONFIGURATION  -  ALTERNATIVE  3 
FIGURE  7 


PSNs  overseas  can  be  obtained  through  various  means. 

They  include  the  use  of  existing  installations  augmented  by 
a  software  package  to  perform  the  PSN  functions,  development 
of  a  new  family  of  nodal  equipment/software,  procurement  of 
additional  CONUS  type  PSNs  for  overseas  deployment.  Government 
purchase  and  installation  of  CONUS  type  AUTODIN  II  hardware, 
as  well  as  various  additional  combinations/permutations  of 
these  approaches.  The  option  selected  as  offering  the  most 
realistic  opportunity  is  the  GFE  purchase  and  installation 
of  CONUS  type  AUTODIN  II  hardware.  The  Government  could 
provide  the  hardware  overseas  and,  owning  the  AUTODIN  II 
software,  load  the  CONUS  software  package  into  the  overseas 
installations.  This  approach  requires  funds  for  Government 
procurement,  which  is  now  under  study  by  the  AUTODIN  II 
Program  Manager . 

(a)  Cost  Implications.  The  WSEO  paper  "A 
Transition  Strategy  Study  to  Interconnect  WWMCCS  ADP  Systems." 
April  1977,  provides  a  meaningful  cost  analysis  for  justifi¬ 
cation  of  the  European  PSN.  Connectivity  to  the  overseas 
sites  will  require  multiplexers  and  lines  outside  of  CONUS 

to  allow  all  traffic  to  be  "back  hauled;"  that  is  a  message 
sent  from  one  European  location  to  another  European  site 
would  cross  the  Atlantic  and  then  return  to  the  destination 
site.  Communications  costs  for  WWMCCS  ADP  in  the  PACOM  and 
EUCOM  areas  were  further  analyzed  under  this  condition.  The 
study  showed  if  dedicated  lines  were  used  for  access  to 
European  commands  with  multiplexers  in  Europe,  approximately 
(DELETED)  would  be  required  annually  for  connection 

to  the  AUTODIN  II  network  in  CONUS.  However,  if  an  AUTODIN 
II  PSN  was  installed  in  Europe .communications  cost  to  WWMCCS 
ADP  would  be  reduced  to  (EEL*H.D)  As  it  would  cost 

approximately  (DELETED)  '  to  install  a  PSN  in  Europe  and 
as  WWMCCS  ADP  use  alone  almost  justifies  its  cost,  it  appears 
logical  to  install  an  AUTODIN  II  PSN  in  Europe  providing 
additional  user  requirements  can  also  be  satisfied.  Likewise, 
a  (EELETED)  in  WWMCCS  ADP  connectivity  costs  is 

obtained  if  an  AUTODIN  II  PSN  is  installed  in  Hawaii.  If 
sufficient  other  user  traffic  existed  in  the  Pacific, 
installation  of  an  AUTODIN  II  PSN  in  the  Pacific  could  also 
be  warranted.  Refer  to  Section  II.  D.  for  system  requirements. 

(b)  Schedule.  It  is  estimated  that  PSNs  overseas 
could  be  implemented  in  the  1981  timeframe.  Scheduling  of  the 
overseas  AUTODIN  II  PSN  approach  is  highly  contingent  on  the 
CONUS  schedule  and  activation  of  contract  options.  A  four  PSN 
network  is  being  provided,  with  options  for  four  or  more 
additional  PSNs.  Expansion  to  overseas  could  be  through  use 
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of  two  of  the  four  expansion  systems  which  would  reduce  the 
overall  schedule  and  could  provide  earlier  implementation  of 
PSNs  overseas.  If  no  options  are  available,  then  it  is  esti¬ 
mated  a  minimum  of  12  months  would  be  required  just  to  acquire 
the  systems.  Analysis  is  underway  to  develop  the  users  needs 
data  base  for  overseas  PSNs.  The  result  of  this  analysis  will 
be  available  by  August  1978,  at  which  time  a  decision  on  early 
implementation  of  overseas  PSNs  will  be  made. 

d.  Conclusions.  Three  alternatives  are  presented  to 
provide  the  best  balance  between  services  offered,  cost  to  users 
and  overall  government  expenditures. 

(1)  Alternative  1  provides  the  required  backbone 
switch  services  in  the  CONUS,  but  it  does  not  identify  any 
AUTODIN  I  ASC  closures  resulting  from  implementation  of 
AUTODIN  II  PSNs.  Also,  it  does  not  offer  AUTODIN  II  service 
to  satisfy  overseas  requirements. 

(2)  Alternative  2  extends  the  AUTODIN  II  program 
in  the  CONUS  and  provides  an  incremental  ASC  closure  approach 
to  allow  sufficient  time  to  test  the  throughput  capability  on 
the  remaining  ASCs.  Also,  it  provides  AUTODIN  II  overseas 
service  through  multiplexing  of  traffic  to  the  CONUS  based 
system. 

(3)  Alternative  3  provides  the  same  AUTODIN  I 
backbone  switch  configuration  as  Alternative  2.  The  difference 
in  this  alternative  is  the  location  of  PSNs  overseas  versus 
using  multiplexing.  Although  PSNs  overseas  would  satisfy 
requirements,  it  is  not  cost  effective  when  compared  to  multi¬ 
plexing  to  the  CONUS.  Documented  user  requirements  do  not  now 
dictate  the  installation  of  PSNs  overseas. 

(4)  Based  on  the  three  alternatives,  it  is  con¬ 
cluded  that  with  implementation  of  eight  PSNs,  it  is  feasible 
to  close  up  to  four  CONUS  ASCs.  Also,  further  study  is  needed 
to  justify  the  implementation  of  PSNs  overseas. 

e.  Recommendation.  Alternative  2  be  selected  as  the 
implementation  alternative  for  backbone  switches. 

C .  Access  Area  Exchanges. 

1.  Definition.  AUTODIN  is  a  system  that  by  definition 
includes  the  ASCs,  interswitch  trunks,  terminals  and  access 
lines.  Until  recent  years,  the  ASCs  were  the  only  really 
automated  elements  of  the  system  doing  such  things  as  switch¬ 
ing  traffic,  storing  it,  maintaining  history,  etc. - all 

automated.  Recently,  telecommunications  center  functions 


became  increasingly  more  automated  and  AUTODIN  terminals  were 
developed  that  started  looking  and  acting  like  AUTODIN  switches. 
These  terminals  are  called  by  various  names  such  as  Local 
Digital  Message  Exchange  (LDMX) ,  Naval  Communications  Process¬ 
ing  and  Routing  System  (NAVCOMPARS) ,  Automated  Multi-Media 
Exchange  (AMME) ,  Automated  Telecommunications  Program  (ATP) , 
and  STREAMLINER.  In  May  1976,  MOP  165  was  revised  to  provide 
guidance  on  the  role  these  Automated  Message  Processing 
Exchanges  (AMPEs)  -  generic  term  for  LDMXs,  NAVCOMPARS, 

AMMEs,  ATPs ,  and  STREAMLINER  -  should  serve  in  the  AUTODIN 
system. 


2.  AMPEs .  These  systems  were  designed  and  developed 
independently  by  the  Services  and  Defense  Agencies  as  a  means 
of  exploiting  the  benefits  of  automation  and  as  a  means  of 
cbhiplying  with  Congressional  guidance  to  reduce  manpower, 
support  costs  and  the  time  required  to  process  and  transmit 
messages.  Each  system  included  in  its  design  specifications 
certain  functions  and  features  which  were  considered  necessary 
to  the  accomplishment  of  the  mission  or  which  reflected  the 
telecommunications  philosopy  prevalent  at  that  time.  As  a 
result,  the  various  AMPE  systems  are  in  many  respects  similar; 
in  other  respects  they  differ  as  widely  as  the  missions  to  be 
performed.  The  time  frame  in  which  the  systems  were  designed, 
with  subsequent  changes  in  Defense  priorities  as  well  as 
significant  techological  advances  in  the  fields  of  telecom¬ 
munications  and  automation  have  accentuated  the  differences 
in  the  AMPEs  as  they  exist  today.  The  following  AMPE  systems 
have  been  studied  for  potential  standardization:  LDMX, 

NAVCOMPARS , AMME ,  ATP  and  the  STREAMLINER.  The  Defense 
Logistics  Agency  (DLA)  AMPEs  were  excluded  in  the  study  because 
of  the  specialized  nature  and  estimated  useful  life  of  the 
equipment.  The  Air  Force  Intermediate  Capacity  Automated 
Telecommunications  Systems (ICATS)  were  not  included  because 
the  data  submitted  did  not  indicate  that  these  AMPEs  performed 
all  of  the  32  evaluated  functions. 

a.  LDMX  and  NAVCOMPARS. 

(1)  Background.  The  Naval  Telecommunications 
Automation  Program  (NTAP )  was  developed . subsequent  to  a  DoD 
study  of  1967  which  recommended  the  development  of  LDMXs.  The 
Subsystem  Project  Plan  (SPP)  for  the  NTAP  was  submitted  to 
OSD  in  early  1969.  In  this  SPP  Navy  combined  the  requirement 
to  automate  telecommunications  services  provided  to  large  shore 
stations  and  the  requirement  for  automating  fleet  telecommunications 
The  resulting  contract  was  to  UNIVAC  in  December  1970  to  provide 
6  LDMX  I  and  4  NAVCOMPARS  I  using  UNIVAC  70/45  equipment.  Refer 
to  Appendix  2  for  equipment  character i sties .  The  NAVCOMPARS 
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performs  all  the  functions  of  the  LDMX  and  also  provides  a 
marked  improvement  in  ship  to  shore  communications.  Since 
the  LDMX  and  NAVCOMPARS  were  specified  in  the  same  contract 
those  features  which  exist  to  automate  ship  to  shore  communi¬ 
cations  and  to  maintain  the  records  required  of  fleet  broad¬ 
cast  have  a  strong  influence  on  both  systems.  In  1974  the 
Navy  identified  requirements  for  additional  automated  systems 
which  could  not  be  satisfied  with  the  UNIVAC  LDMX  contract. 

When  Navy  sought  DoD  approval  of  a  follow-on  LDMX  contract, 

DTACCS  directed  that  Navy  procure  the  required  additional 
hardware  from  the  UNIVAC  AMME  contract  with  the  U.S.  Army. 

(2)  Description.  The  LDMX  is  an  AMPE  used  for 
interface  with  AUTODIN  to  meet  requirements  for  distribution 
of  on-base  record  communications  by  a  naval  telecommunications 
center  or  message  center  serving  fleet  commands  based  ashore, 
and  shore  (field)  activites  in  naval  station/base  complexes. 
NAVCOMPARS,  in  addition  to  providing  all  LDMX  capabilities, 
also  provides  for  the  interface  with  Navy  tactical  environments. 

(3)  Status.  Six  LDMX  Is  and  four  NAVCOMPARS  Is 
are  operational  with  two  test  beds.  The  current  NAVCOMPARS  I 
equipment  will  be  replaced  with  NAVCOMPARS  IIs,  UNIVAC  90/60 
equipment,  freeing  the  U70/4  5  equipment  for  additional  LDMX  I 
installations.  In  addition,  eight  LDMX  Is,  two  LDMX  IIs,  and 
one  NAVCOMPARS  II  are  planned. 

b.  AMMEs. 

(1)  Background.  The  AMME  is  the  principal  tele¬ 
communications  system  identified  in  the  Army  Telecommunications 
Program  (ATCAP) .  The  AMME  was  approved  in  October  1971  by  OSD 
following  DODD  4630.1  action  by  Army.  The  resulting  contract 
with  UNIVAC  in  1973  provided  attractive  discounts  (25%  —  65%)  if 
24  systems  were  procured.  At  that  time  Army  had  identified  27 
locations  for  AMMEs. 

(2)  Description.  AMME  is  designed  to  provide  com¬ 
prehensive  and  improved  communications  center  services,  including 
an  AUTODIN  interface  in  support  of  selected  Army  locations 
around  the  world. 

(3)  Status.  Four  AMMEs  are  operational,  with 

one  test  bed,  and  an  additional  AMME  at  Taegu,  Korea  installed 
and  undergoing  operationalhtests .  In  addition  to  the  six 
installed  systems,  Army  has  plans  for  15  additional  AMME 
installations . 

c .  ATP . 

(1)  Background.  In  May  1972,  the  Air  Force 
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received  initial  approval  for  their  program,  which  identified 
four  levels  of  automation  ranging  from  manual,  medium,  inter¬ 
mediate,  and  large  capacity  systems.  These  latter  three 
categories  of  automation  are  defined  as  AMPEs  and  are  included 
in  the  AMPE  data  base.  In  1973,  Air  Force  began  revising  the 
ATP  to  incorporate  their  concept  of  distributed  processing 
through  an  array  of  mini  processors.  In  1975,  DoD  approved 
the  Air  Force  4630.1  action  for  the  procurement  of  seven 
ATP  systems. 


(2)  Description.  The  ATP  provides  for  modularly- 
expandable  mini-computer  systems  designed  to  be  sized  according 
to  changing  requirements. 

(3)  Status.  Twelve  automated  systems  are 
operational  with  one  test  bed.  The  contract  for  the  ATP  mini¬ 
computer  systems  was  signed  on  12  September  1977  with  C3  Inc., 
and  it  allows  for  one  test  facility  and  six  operational  systems. 


d.  STREAMLINER. 

(1)  Background.  In  August  1973,  the  STREAMLINER 
program  received  approval  for  32  systems.  designed  t0 

automate  the  CRITICOM  terminal,  to  reduce  ^iter-to-read' BL  ld 
time  and  to  provide  the  benefits  of  automation  cmopAMLlNER 
sites.  More  than  any  other  automation  program,  STREAMLINER 
received  its  impetus  from  the  Pueblo  and  i^erty  incidents- 
These  incidents  focused  attention  on  the  handling  of  critical 
communications  in  particular  and  all  intelligence  «a- 
tions  in  general.  The  STREAMLINER  system  is  designed  to 
vide  the  required  communications  automation  at  minimum  p 

cost. 


(2)  Description.  STREAMLINER  provides  for  auto¬ 
mation  for  the  telecommunications  centers  serving  the  Service 
Crypto logical  Agencies  and  NSA/CSS  field  activities  The 
svstem  was  designed  to  eliminate  the  manual  recorded  message 
JrScIssIng  iuncfions  performed  in  SIGINT  telecommunications 
centers.  Direct  electronic  interface  with  computer  based 
SIGINT  mission  systems  is  also  provided.  The  system  processes 
both  GENSER  (JANAP  128)  and  DSSCS  (DOI  103)  messages. 

(3)  status.  Twenty-six  systems  are  operational. 
Five  additional  systems  will  be  installed  by  March  19 

e.  Functional  Comparison.  A  comparison  of  system 
characteristics  and  functions  performed  by  the  AMPEs  is  pro¬ 
vided  in  Appendix  2.  In  this  comparison  the  functions 
categorized  as  follows: 
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(1)  AUTODIN  Svstem  Functions.  This  category 
includes  those  functions  that  are  required  of  all  terminals 
served  by  AUTODIN. 

(2)  Telecommunications  Center  Functions.  This 
category  includes  those  functions  performed  either  manually, 
automatically  or  semi-automatically  at  all  telecommunications 
centers. 

(3)  Customer  Assistance  Functions.  These  are 
functions  which  are  not  inherently  telecommunications  center 
functions,  but  which  can  be  more  efficiently  performed  at  the 
telecommunications  center  than  at  the  user  facility. 

(4)  Physical  Characteristics.  Physical/electri¬ 
cal  characteristics  of  the  systems. 

The  Phase  I  AMPE  functional  comparison  study  concluded  that 
there  existed  more  commonality  than  disparity  in  system 
functions,  and  that  total  intersystem  compatibility  could 
best  be  achieved  through  a  centrally  planned  and  controlled 
evolution.  In  a  follow-on  study,  a  more  detailed  technical 
evaluation  of  the  AMPE  systems  was  performed.  The  study, 
termed  the  Phase  II  AMPE  Comparison  Study,  provided  an  evalu¬ 
ation  of  each  of  32  performed  functions  for  potential 
standardization.  Twenty-six  functions  were  indicated  as 
offering  potential  for  standardization.  The  detailed  analysis 
of  these  two  AMPE  studies  are  provided  in  Appendix  2.  A  third 
phase  of  the  AMPE  comparison  analysis  is  now  in  progress.  Its 
objective  is  the  determination  of  the  feasibility  and  cost- 
effectiveness  of  modifying  existing  AMPEs  to  provide  functional 
standardization.  In  this  phase,  candidate  functions  will  be 
selected  from  the  three  categories  of  functions  previously 
analyzed.  These  candidate  functions  will  be  evaluated  and  a 
"strawman"  standard  for  that  function  will  be  selected.  The 
Services/Agencies  will  then  analyze  the  impact  of  using  the 
selected  "strawman"  standard  for  each  of  the  candidate  functions. 
THe  IASA  Technical/Policy  Panel  will  then  recommend  whether  it 
is  cost-effective  to  standardize  present  and  near  term  AMPEs. 

All  three  phases  of  the  AMPE  study  effort  are  providing  a 
definition  of  functions  required  to  project  a  new  generation 
of  AMPE  equipment,  functionally  specified  as  an  Inter-Service/ 
Agency  standardized  AMPE. 


f.  Profile.  Table  4  provides  a  breakout  of  Service/ 
Agency  AMPEs  into  three  categories:  installed,  approved  for 
installation,  and  projected  but  not  yet  approved  for 
installation. 

TABLE  4 
AMPE  PROFILE 


Installed 

Approved 

Projected 

Total 

Army 

6 

2 

13 

21 

Navy 

12 

2 

9 

23 

Air  Force 

13 

0 

8 

21 

DLA 

18 

0 

0 

18 

NSA 

26 

5 

0 

31 

TOTAL 

75 

9 

30 

114 

Of  the  total  114  AMPEs  encompassing  all  Service/Agency  pro¬ 
grams,  39  remain  to  be  installed  through  1982.  Of  those  39 
to  be  installed,  only  9  have  gone  through  formal  installa¬ 
tion  approval,  leaving  30  systems  requiring  approval. 

The  AMPE  installation  schedule  is  shown  in  Table  5. 


TABLE  5 

AMPE  INSTALLATION  SCHEDULE* 


FY  78  FY  79  FY  80  FY  81  FY  82 


A 

N 

AF 

NSA 

A 

N 

AF 

NSA 

A 

N 

AF 

NSA 

A 

N 

AF 

NSA 

A 

N 

AF 

NSA 

CONUS 

1 

1 

1 

6 

2 

2 

3 

0 

2 

2 

3 

0 

5 

2 

5 

0 

0 

3 

5 

0 

EUROPE 

1 

1 

0 

3 

1 

0 

1 

0 

2 

0 

0 

0 

1 

1 

0 

0 

0 

0 

0 

0 

PACIFIC 

1 

0 

0 

0 

0 

3 

0 

0 

0 

0 

2 

0 

0 

0 

1_ 

0 

0 

0 

0 

0 

TOTAL 

3 

2 

1 

9 

3 

5 

4 

0 

4 

2 

5 

0 

6 

3 

6 

0 

0 

3 

5 

0 
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♦The  following  notes  apply  to  Table  5: 


-  During  FY  1/78  5  AMPEs  were  installed  (4  NSA  and  1  Army) 

-  Navy  figures  reflect  installation  of  15  AMPEs  during 
fiscal  years  78-82;  purchase  of  Navy  AMPEs  is  limited 
to  7  (4  of  which  are  for  use  in  upgrading  current 
NAVCOMPARS) ;  the  remaining  8  installations  include 
re-use  of  LDMX  equipment. 

-  Air  Force's  ATP  implementation  during  FY  78  is  one 
test  bed  system.  Six  ATP  systems  now  under  contract 
are  projected  to  be  installed  beginning  March/April  1979 
Follow-on  ATP  system  are  projected  to  cost  effectively 
replace  UNIVAC  418II/III  computer  systems  as  well  as 

to  upgrade  capabilities  at  designated  locations  to 
enable  TCC  consolidation  and  extension  of  automation. 

Contractual  commitments  incurred  by  the  Army  through 
the  AMME  contract  will  be  satisfied  through  both  Army 
and  Navy  equipment  purchases  as  of  FY  80.  If  the 
scheduled  implementation  is  followed  as  shown  above, 
the  commitment  will  be  satisfied  by  mid-1980. 

Table  6  provides  the  AMPE  procurement  costs  by  fiscal  year. 
Total  program  costs  are  not  presented  to  include  site 
preparation,  software,  logistics  support  and  training. 

TABLE  6 

AMPE  PROCUREMENT  COSTS 


(TABLE  EELETED) 


3.  Implementation  Alternatives.  Based  upon  the  completed 
AMPE  functional  comparison  studies  (Phase  I/II)  and  the 
in-progress  cost  analysis  study  (Phase  III) ,  the  following 
are  AMPE  implementation  alternatives: 

a.  Alternative  1.  Continue  current  AMPE  Programs. 
Install  the  Service/Agency  39  AMPEs  over  the  FY  78-82  time 
frame,  at  a  cost  approximating  (DELETED) 

b.  Alternative  2.  Inter-Service/Agency  AMPE  Program. 
There  are  two  approaches  to  this  alternative: 

(1)  Alternative  2A.  Implement  an  Inter-Service/ 
Agency  AMPE  program  using  available  AMPE  resources. 

(a)  After  analysis  of  the  AMPE  Phase  II 
Comparison  Study  data  (Appendix  2) ,  it  was  concluded  that  three 
AMPEs  are  viable  candidates  for  near-term  implementation  as 
inter-Service/Agency  AMPEs.  These  are  the  Navy  LDMX/NAVCOMPARS , 
the  Army  AMME,  and  the  Air  Force  ATP.  The  Streamliner,  on  the 
other  hand,  was  designated  to  provide  the  minimum  required 
automation  of  the  CRITICOM  network  at  the  minimum  possible  cost, 
with  austerity  of  the  system  influencing  the  available  features 
and  the  manner  in  which  the  telecommunications  functions  are 
performed.  Based  on  the  above  factors,  the  Streamliner  is  not 
recommended  as  a  candidate  inter-Service/Agency  AMPE. 

(b)  If  the  AMPE  Phase  III  Cost  Analysis 
Study  concludes  that  it  is  cost-effective  to  standardize  ore- 
sent  AMPEs  then  a  standard  inter-Service/Agency  AMPE  would 

be  recommended  for  use  by  all  DoD  components. 

(2)  Alternative  2B,  Implement  an  Inter-Service/ 
Agency  AMPE  program  based  upon  functional  specifications  to 
be  developed  by  August  1979.  These  specifications  could  be 
used  to  enter  a  development  phase  from  which  industry  could 
provide  the  hardware  and  software  needed  for  implementation. 

c.  Conclusions.  AMPE  Alternatives  1  and  2,  presented 
above,  do  not  necessarily  offer  two  divergent  approaches  to 
satisfying  Service/Agency  requirements. 

(1)  Alternative  1  offers  the  Services/Agencies 
the  greatest  degree  of  flexibility  in  satisfying  their  current 
and  projected  needs,  but  it  does  not  facilitate  the  sharing 
of  technology  among  the  Services  and  Defense  Agencies. 
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Standardization  does  offer  the  potential  for  reduction  of  cost 
and  increased  inter-Service/Agency  interoperability,  but  it 
must  be  carefully  controlled  to  ensure  flexibility  to  meet 
changing  user  requirements  and  to  incorporate  new  technology 
and  techniques  afforded  by  the  continually  changing  state-of- 
the-art. 


(2)  Alternative  2  provides  for  an  inter-Service/ 
Agency  AMPE  program  through  one  of  two  approaches,  that  is, 
using  current  AMPE  resources  or  based  on  functional  specifi¬ 
cations  to  be  developed  by  August  1979.  The  former  approach 
offers  a  circa  1980  implementation  schedule  based  on  availa¬ 
bility,  while  the  latter  approach  has  an  implementation 
schedule  in  the  1983  time  frame. 

(3)  From  the  AMPE  functional  comparison  studies 
it  is  concluded  that  26  out  of  32  evaluated  telecommunication 
functions  have  a  high  degree  of  commonality. 

(4)  An  inter-Service/Agency  AMPE  program  is  viable, 
and  the  AMPE  cost  analysis  study  will  aid  in  determining  the 
access  area  AUTODIN  architecture. 

d.  Recommendation.  Alternative  2B  be  selected  as  the 
implementation  alternative  for  AMPEs. 

D.  Terminals . 

1.  Definition.  A  user  terminal  is  that  input/output 
device  which  is  the  ultimate  source  and  destination  of  the 
data  traffic  being  handled  by  the  network.  All  intermediate 
sources  and  destinations  of  traffic  (e.g.,  an  AMPE)  are  nodes 
where  communications  services  are  performed.  Previously  all 
subscribers  directly  connected  to  ASCs  were  lumped  together 
as  terminals  without  regard  to  their  actual  hierarchical 
status.  Thus,  AMPEs  were  labeled  as  AUTODIN  terminals  even 
though  AMPEs  function  as  nodes,  not  user  terminals.  (Note: 

It  is  possible  that  some  devices  may  be  labeled  as  AMPEs  which 
perform  user  terminal  functions  in  addition  to  the  normal  nodal 
functions  associated  with  AMPEs.)  Depending  on  functional  use 
and  hierarchical  location,  such  a  device  will  be  functionally 
designated  as  either  a  node  or  a  user  terminal.  Functional 
specifications  for  a  "Common  Family  of  AUTODIN  Terminals"  also 
apply  to  AMPEs. 

a.  User  terminals  are  assumed  to  be  duplex.  Receive- 
only  and  transnit-only  units  will  be  dealt  with  on  a  case- 
by-case  basis.  Terminals  include,  as  a  minimum: 
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(1)  Very  simple  duplex  devices  (e.g.,  tele¬ 
typewriters)  ; 

(2)  Controlled,  hard-wired  logic  devices  (e.g.. 
Teletypewriter  Control  Unit/Teletypewriter  AUTODIN  I  Mode  V, 
and  Digital  Subscriber  Terminal  Equipment) ; 

(3)  Controlled,  software  programmalbe  devices 
(e.g.,  DCT-9000  used  as  an  AUTODIN  I  Mode  I  terminal,  the 
Standard  Remote  Terminal  (SRT)  and  microprocessor  controlled, 
buffered  terminals); 

(4)  Sophisticated  software  programmable  processor 
capabilities  (e.g.,  host  ADP  installations  connected  to 
AUTODIN  II). 


b.  Supporting  the  traffic  through  the  AUTODIN  are  a 
variety  of  terminals  possessing  certain  parameters  of  speed, 
mode,  and  inherent  automation  of  message  processing  functions. 
The  following  definition  applies  to  the  terminal  parameters: 

(1)  Speed.  The  rate  of  traffic  exchange  between 
terminal  and  switch; 

(2)  Mode.  The  protocol  by  which  traffic  is  trans¬ 
mitted  from  terminal  to  switch  (presence  or  lack  of  error 
controls  and  synchronization) ; 

(3)  Automation  of  processing  functions.  The 
message  processing  functions  automated  within  the  terminal 
equipment,  either  through  hardware/software/firmware  or 
combinations  thereof. 

c.  The  current  exchange  of  information  between  users 
of  the  AUTODIN  is  in  the  form  of  narrative  text,  card  data,  and 
magnetic  tape  data  message  traffic.  Supporting  these  exchanges 
are  the  formats  for  entry  and  exit  from  the  switched  network 
including  JANAP  128,  JANAP  128  modified,  and  ACP  127.  The 
following  are  the  daily  averages  of  AUTODIN  message  traffic 
sampled  one  day  a  month  over  a  twenty  month  period  (May  1976 

to  December  1977) : 


9 
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TA3LE  7 


DAILY  AUTCDIN  TRAFFIC 


Nature  of  Traffic  Message  Entry 


Message  Exit* 


Narrative 

Card 

Mag  Tape 


105, 915  msgs 
83,461  msgs 
1,392  msgs 


269, 414  msgs 
77, 615  msgs 
1,311  msgs 


*Low  exit  figure  explanation:  Messages  not  recorded  as 
delivered  due  to  recording  period,  time  of  entry  into 
system  and  length  of  message-  In  fact,  messages  are  in 
system  at  ime  of  statistic  recording,  awaiting  delivery 
to  stations  such  as  part-time  centers. 


2.  Profile.  Changes  have  been  shown  in  the  speed,  mode 
and  automation  of  terminals. 


a.  Shift  to  Higher  Terminal  Speeds.  Since  1975, 
the  net  change  in  medium  and  high  speed  Mode  I  terminals 

is  +55  with  a  corresponding  decrease  of  -92  in  the  lower  speed 
Mode  I  terminals.  Therefore,  there  is  a  net  decrease  of  37 
Mode  I  terminals  over  the  past  two  years.  However,  there  has 
been  an  increase  of  3.4%  in  message  volume  and  an  11%  increase 
in  lineblocks  during  this  period. 

b.  Mode  Shift.  Increases  in  processing  capability 
provided  through  the  presence  of  programmable  terminals  has 
brought  a  reduction  of  the  low  speed  Mode  V  terminals  connected 
to  AUTODIN.  Since  1975,  a  total  of  45  Mode  V  terminals  have 
been  eliminated.  Also  there  has  been  an  increase  of  79  Mode  II 
terminals,  attributed  primarily  to  the  installation  of  query/ 
response  terminals  for  the  Naval  Investigative  Service.  There 
was  no  discernible  intermode  shift  (i.e..  Mode  V  to  Mode  I); 
rather,  intramode  (Mode  I  low  to  Mode  I  high)  shifts  were 
dominant . 


c.  Programmable  versus  nonprogrammable  terminals. 

A  total  of  345  terminals  (26%  of  the  total  1322)  possess  some 
degree  of  software  capability.  Although  management  tends  to 
concentrate  on  automated  terminals  and  their  inherent  costs, 
the  above  statistic  illustrates  the  point  that  the  greater 
proportion  of  AUTODIN  subscribers  have  little  capability  beyond 
traffic  input  and  output  processing. 

d.  Influencing  Factors.  There  are  several  influencing 
factors  that  impact  terminal^perations . 

(1)  Remote  Terminals.  The  advent  of  the  AMPE 
serving  multiple  customers  has  brought  a  shift  in  the  AUTODIN 
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architecture  moving  AUTODIN  terminals  as  remotes  to  the  AMPEs. 
To  date,  however,  that  impact  has  been  negligible.  By  FY  1980, 
the  number  of  remote  terminals  serving  customers  off  the 
backside  of  AMPEs  is  projected  to  increase  to  at  least  127. 

This  projection  is  predicated  upon  the  approval  and  subsequent 
installation  of  currently  planned  terminals  to  that  date. 

The  desirability  of  using  remote  terminals  stems  from  the 
concept  of  operations,  where  large  volumes  of  traffic  can  be 
automatically  processed  in  an  AMPE  with  remote  subscribers 
using  only  inexpensive  input/output  devices. 


(2)  Terminal  Leasing.  Current  practice  among  the 
Services/Agencies  is  the  leasing  of  AUTODIN  terminals.  Since 
1975,  there  has  been  a  three  percent  increase,  41 %  to  44%,  in 
the  number  of  leased  AUTODIN  I  terminals.  These  figures 
indicate  an  expanding  interest  in  terminal  lease  arrangements. 
T h e^mont^h  1  y  AUTODIN  terminal  lease  cost  is  approximately 


(3)  Manpower  reductions.  The  concern  for  achieving 
cost-effectiveness  in  terminal  operations  has  guided  the  Services 
in  their  adopting  terminal  programs  tailored  to  reduced  manpower 
levels.  The  visible  effects  on  this  factor  include  interest  in 
use  of  automation  wherever  feasible  and  cost-effective. 

3.  Programs .  The  variety  of  terminal  equipments  in  use 
today  require  program  support  of  significant  degree  considering 
training,  maintenance,  software  support,  and  logistics.  The 
existence  of  multiple  terminal  programs  is  due  to  differences  in 
functional  requirements  and  the  existence  of  competitive  equip¬ 
ment.  Since  not  all  terminals  have  equivalent  capability,  it 
has  been  necessary  for  the  Services/Agencies  to  assume  program 
responsibility  for  various  terminal  equipments  to  ensure  the 
spectrum  of  communications  requirements  are  satisfied  cost- 
effectively.  A  corresponding  overlap  in  the  functional  capa¬ 
bility  of  competitive  equipment  is  based  on  the  competition  for 
government  dollars.  Consequently,  the  Services/Agencies  have 
been  afforded  the  opportunity  to  be  selective  in  terminal  equip¬ 
ments,  tailoring  their  terminal  to  precisely  meet  needs.  The 
result  is  they  have  assumed  program  responsibility  for  terminals 
from  different  manufacturers,  with  similar  capabilities  to  other 
Service/Agency  terminals.  The  following  is  a  listing  of  known 
active  or  pending  programs  developed  by  the  Services/Agencies 
for  terminal  equipments  provided  by  level  of  message  processing 
requirements . 

a.  Level  I-Teletypewriter  (TTY)  equipment.  Require¬ 
ments  of  the  nature  involving  only  narrative  traffic  at  low 
speeds  (asynchronous)  are  satisfied  using  TTY.  Currently, 
there  exist  two  main  programs  for  TTY.  Western  Union 
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provides  leased  TTY  equipment  on  a  large  scale.  The  Army  has 
recently  proposed  a  program  to  replace  current  TTY  equipment 
using  a  Cathode  Ray  Tube  (CRT)  TTY.  If  adopted,  this  program 
would  significantly  increase  the  computer  resources  in  the 
government  inventory.  Message  preparation  times  can  be 
significantly  increase  the  computer  resources  in  the  government 
inventory.  Message  preparation  times  can  be  significantly  reduced 
through  use  of  the  CRT  equipment.  Editing  and  correction 
functions,  which  in  TTY  applications  require  message  proofs  for 
editing  and  tape  reruns  for  correction,  can  be  accomplished  much 
more  swiftly  using  the  CRT  equipment.  Currently,  the  Army  is 
planning  installation  of  approximately  1400  units  during  the 
period  FY  79-82.  The  Navy  expressed  interest  in  also  replacing 
outdated  TTY  equipment  and  voiced  support  for  a  DCA  recommended 
joint  Required  Operational  Capability  (ROC)  for  this  equipment. 

Air  Force  has  undertaken  a  program  to  procure  similar  equipment. 

To  date,  there  has  oeen  no  action  initiated  to  consolidate  the 
requirements  and  procurement  of  this  equipment.  When  the 
procurement  is  undertaken,  it  is  recommended  that  the  lease  with 
purchase  option  acquisition  be  adopted.  This  procurement • approach 
will  allow  the  Services/Agencies  the  flexibility  to  apply  state 
of  the  art  advances  as  they  accrue,  with  minimum  investment  loss, 
and  to  accommodate  the  common  family  of  terminals  application 
as  it  becomes  available. 

b.  Level  II-Digital  Subscriber  Terminal  Equipment  (DSTE) . 
Requirements  for  card  and  narrative  traffic  (Mode  I)  are 

in  part  satisfied  by  the  DSTE.  There  are  approximately  375  DSTE 
terminals  in  the  current  inventory.  However,  the  age  of  this 
manual  terminal  equipment  led  to  the  evaluation  of  the  Standard 
Remote  Terminal  (  SRT)  replacement  for  the  DSTE.  Service/Agency 
inputs  are  included  as  Table  8.  Both  Army  and  Navy  consider  the 
SRT  a  suitable  replacement  for  their  DSTEs;  however,  NSA  and  DIA 
preferred  use  of  other  systems  to  the  SRT.  NSA  maintained  that 
Project  RAILBED,  designed  to  provide  a  more  versatile  STREAMLINER/ 
AUTODIN  interface  to  replace  the  Common  Control  Unit  (CCU)  and 
Teletypewriter  Adapter  Module  (TAM),  and  Project  PULLBOAT, 
designed  to  provide  TEMPEST  approved  Card  Communications  Terminals 
( CCT)  at  STREAMLINER  sites,  will  satisfy  DSTE  replacement  require¬ 
ments.  DIA  specified  replacing  DSTEs  with  PDP-11/45  equipment  to 
satisfy  their  requirements.  The  Air  Force  maintains  the  presence 
of  the  DSTE  equipment  returned  to  the  inventory  upon  its  replace¬ 
ment  with  the  SRT  by  the  Army  and  Navy  will  provide  sufficient 
reserve,  allowing  continued  support  of  the  DSTEs  they  currently 
employ. 

c.  Level  III-SRT.  Requirements  for  terminals  serving 
as  input/output  devices  connected  to  large  processing  systems 
and  having  the  capabilities  of  narrative,  card,  and  magnetic  tape 
are  satisfied  by  the  SRT  program.  The  SRT  is  a  TEMPEST  certified 
terminal  providing  a  modular  approach  to  achieving  various  hardware 
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configurations  via  a  broad  selection  of  peripheral  devices. 

There  are  two  key  factors  aside  from  mandatory  requirements 
application  that  influence  DoD  use  of  the  SRT:  (1)  system 
availability  and  (2)  government  obligation  as  set  forth  in 
the  SRT  contract.  System  availability  has  been  established  by 
the  SRT  contract  (awarded  on  22  August  1975) ,  the  initial  equip¬ 
ment  delivery  order  (given  on  22  July  1977) ,  and  the  Army- 
determined  distribution  schedule) .  The  second  influencing 
factor  in  the  DoD  use  of  the  SRT  is  that  the  SRT  contract  specifies 
that  the  government  shall  purchase  a  minimum  of  200  configu¬ 
rations  with  a  projected  cost  to  the  government  of  approximately 
(TSFUSTED)  .  Employment  of  a  system  towards  which  significant 

resources  have  already  been  obligated  should  receive  due 
consideration  in  determining  Service/Agency  use  of  the  SRT. 

The  following  paragraphs  will  discuss  the  SRT  capabilities  and 
costs  associated  with  contractual  commitments  and  the  engineering 
changes . 

(1)  Capabilities.  The  SRT  has  demonstrated, 
in  the  Army  testbed  model,  the  capability  to  transmit  and 
receive  data  and  narrative  traffic  using  SRT  to  SRT  via 
local  switching,  SRT  to  AMME  to  SRT  with  message  processing 
accomplished  in  the  AMME,  and  SRT  to  AUTODIN  to  SRT.  Devices 
available  in  the  SRT  operation  included  Magnetic  Tape, 

Optical  Character  Reader  (OCR) ,  Paper  Tape  Punch/Reader, 
Low/Medium/High  Speed  Printer,  Card  Reader/Punch,  and  Disk. 

Device  to  Device  transfer  between  peripherals  has  also 

been  demonstrated  along  with  the  capacity  to  provide  JANAP 
128  format  message  generation  with  editing,  masks  for  easy 
message  preparation,  and  error  condition  notification.  Army 
SRT  testing,  leading  to  its  conditional  acceptance  on  8  July 
1977,  indicated  that  further  contractor  development  was 
necessary  prior  to  placing  the  SRT  in  service.  Cost  influencing 
Engineering  Change  Proposals  (ECP)  related  to  human  engineer¬ 
ing  factors  have  also  been  submitted  by  the  Navy  to  ensure 
the  SRT  will  be  operationally  acceptable.  In  addition,  the 
Army  has  undertaken  software/firmware  enhancements  to  the 
SRT  for  expansion  to  a  capability  comparable  with  current 
automated  terminals. 

(2)  Cost/Engineering  Changes.  During  Fiscal 
Year  1979  final  costs  attributed  to  system  changes  will 

be  available  to  the  Services/Agencies .  Impacting  on  these 
costs  is  an  annual  seven  percent  escalation  factor  applied 
to  system  costs.  The  effect  of  cost  increases  may  reduce 
the  competitive  edge  necessary  for  cost-effective  SRT 
application.  Further  cost  analysis,  as  figures  become 
available,  is  in  order  to  ensure  the  SRT  is  economically  suit¬ 
able  for  satisfying  terminal  requirements.  Costs  associated 
with  the  ECPs  have  not  been  included  with  the  SRT  cost. 


(3)  Summary.  The  use  of  the  SRT  is  predicated 
upon  matching  the  capabilities  and  cost-effectiveness  of 
the  system  against  communications  requirements.  The 
Services  and  Agencies  were  requested  as  part  of  an  IASA 
working  group  effort  to  examine  the  SRT  for  possible  use 

in  view  of  the  established  capabilities,  proposed  modifica¬ 
tions,  and  currently  known  system  costs.  As  a  result  of 
the  working  group  effort,  it  was  determined  that:  (1)  the 
SRT  can  satisfy  a  major  segment  of  the  communications 
terminal  requirements  of  the  Services/Agencies;  (2)  imple¬ 
mentation  of  recently  identified  engineering  change  proposals 
will  correct  deficiencies  noted  in  engineering  and  operational 
suitability  evaluations;  (3)  an  obstacle  to  immediate  DoD 
application  of  the  SRT  is  its  availability;  (4)  application 
of  the  SRT  is  contingent  upon  its  cost-effectiveness  when 
compared  with  other  terminal  equipments.  Costs  of  the  SRT 
modification  may  serve  as  a  mitigating  factor  against  Services/ 
Agencies  use  of  the  SRT. 

(4)  Recommendations.  The  following  recommenda¬ 
tions  are  provided  with  respect  tc  the  disposition  of  the  DoD 
use  of  the  SRT: 

(a)  to  continue  the  case-by-case  waiver 
for  use  of  comparable  AUTODIN  terminal  equipment  until  the 
Standard  Remote  Terminal  is  available; 

(b)  that  the  Army,  as  the  SRT  Program 
Manager,  pursue  quantity-discount  price  negotiations  with 
the  SRT  contractor; 

(c)  cost  analysis  of  the  SRT  versus 
comparable  terminal  equipment  should  be  undertaken  by  Services/ 
Agencies  when  final  SRT  cost  figures  are  available. 

d.  Level  IV-Automated  Terminals.  Requirements 
involving  automation  of  processing  functions  for  card,  narrative, 
and  magnetic  tape  traffic  are  satisfied  by  a  multitude  of 
programs.  Several  reasons  for  the  many  programs  are: 

(1)  Degree  of  automation.  There  are  require¬ 
ments  for  various  degrees  or  functional  automation  resulting 
from  the  need  for  efficient  communications  center  operations. 

(2)  Software  dependency.  The  procedural 
variations  that  exist  among  the  Services/Agencies  have 
resulted  in  the  development  of  singularly  anplied  soft¬ 
ware  programs.  Further,  since  automation  of  the  functions 
is  selectable,  heavy  reliance  on  the  use  of  software  has 
occurred. 


* 


(3)  Standardization.  The  reliance  on  software 
to  perform  processing  functions  has  restricted  the  stan¬ 
dardization  of  the  terminal  systems  to  a  large  degree.  Since 
software  is  machine  dependent,  the  normal  uniqueness  of  the 
software  programs  has  prohibited  the  multi-service  operation 
of  terminals.  The  programs  supporting  the  automation  of 
message  processing  functions  include  the  following: 

(a)  DCT-9000.  All  the  Services  have 
applied  the  DCT-9000  in  varying  configurations  and  quantities 
towards  terminal  requirements.  After  installation  of  the 
most  recently  identified  requirement,  the  total  DCT-9000 
population  will  exceed  200  units.  The  flexibility  of  the 
system  and  recent  price  advantages  to  be  realized  through 
quantity  purchase  have  made  the  DCT-9000  equipment  cost- 
effective  in  medium  volume  message  centers.  Functions 
included  in  the  capability  of  the  DCT-9000  terminal  include 
paper  tape,  card  and  magnetic  tape  processing. 

(b)  Others.  There  are  six  other  identifi¬ 
able  terminal  progjfaflis  supporting  the  communications  center 
terminal  automation.  These  include  programs  for  procurement 
and  operation  of  IBM,  Mohawk  Data,  CommTen,  Burroughs, 

Control  Data,  and  Honeywell  systems,  which  total  88  equipments. 
AMPE  programs  are  analyzed  separately. 

e.  The  Services/Agencies  have  undertaken  programs 
to  automate  selective  telecommunications  center  functions. 

(1)  Optical  Character  Recognition  Equipment 
(OCRE) .  There  are  several  on-going  OCRE  programs: 

(a)  JCS  directed  the  Army  to  serve  as 
program  manager  for  the  development  and  procurement  of 
three  OCRE  configurations  to  satisfy  all  Services/Agencies 
requirements.  These  configurations  are  as  follows: 

1.  Configuration  A.  Reader  only, 
with  plain  language  address  (PLA)  to  routing  indicator  (RI) 
conversion  and  error  correction  to  be  accomplished  by  the 
terminal  system. 


2.  Configuration  B.  Automatic  format 
conversion  of  DD  173  messages  to  JANAP  128  with  error 
correction  and  plain  language  address  (PLA)  to  routing 
indicator  (RI)  conversion,  accomplished  through  interactive 
video  display  unit  (VDU)  capability. 

3.  Configuration  C.  A  fully  automated 
message  entry  system  providing  format  conversion  from  DD  173 
to  JANAP  128  and  PLA  to  RI  conversion  with  complete  error 
correction  and  editing  capability  through  an  interactive  VDU. 
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In  the  development  process  the  Services  provided  the  Army 
a  listing  of  functional  requirements  and  quantities  desired 
from  which  a  set  of  specifications  were  prepared  by  DCA. 

These  specifications  were  forwarded  to  the  Army  for  their 
use  in  OCRE  development.  The  equipment  specified  has  not 
been  made  available  to  the  Services  at  this  time.  Impacting 
the  development  of  the  Army  system  was  a  decision  by  ASD 
(C^I)  that  the  SRT  hardware  be  used  to  provide  the  three 
configurations  of  OCRE. 

(b)  The  ASD  (C3I)  directed  the  Air  Force 
develop  a  stand  alone  OCRE  similar  to  the  C  configuration 
and  further  requested  the  other  Services/Agencies  be  queried 
as  to  their  use  for  this  system.  The  Navy  and  DLA  expressed 
interest.  The  system  used  is  the  Lundy  Farrington  OCRE, 
already  in  the  Air  Force  inventory. 

(c)  There  are  currently  approximately  164 
OCREs  in  use  by  the  Services/Agencies.  The  reason  for 
application  of  this  system  on  such  a  widespread  basis  is  the 
inherent  cost  savings  that  can  be  realized  in  the  reduction 
of  manpower  through  the  automation  of  manpower  intensive 
functions  rather  than  complete  message  processing.  Program 
considerations  revealed  the  existence  of  five  vendors 
actively  supporting  equipment  requirements.  Tailored 
application  of  the  systems  to  satisfy  requirements  has  been 
undertaken  by  the  Services/Agencies. 

(d)  The  following  actions  have  been 
sponsored  by  the  DCA  in  an  effort  to  achieve  standardization 
of  development  and  application  of  OCRE. 

2-  A  review  has  been  undertaken  of  the 
original  specifications  for  the  three  configurations  and  is 
expected  to  produce  a  set  of  standard  OCRE  specifications 
for  all  DoD  use.  Ancillary  to  the  development  of  standard 
OCRE  specifications,  the  DCA  has  also  forwarded  the  MCEB 
a  revised  DD  173  format  for  DoD  use  in  conjunction  with  the 
standard  OCRE. 

2.  Development  of  a  cost-ef f ective- 
ness  model  for  OCRE  installation  regardless  of  the  configura¬ 
tion  used.  This  model  will  be  used  by  DCA  in  the  evaluation 
of  the  Service/Agency  automation  plans  when  OCRE  is  involved. 

2*  The  Army  performed  an  analysis  of 
OCRE  acquisition  alternatives.  The  result  of  the  analysis 
was  to  provide  a  recommended  procurement  alternative  based 
on  comparison  of  all  known  programs  for  the  three  OCRE 
configurations.  Army  recommended  that  a  competitive  procure¬ 
ment  be  undertaken  using  the  revised  specifications,  and  in 
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the  interim,  the  Services/Agencies  acquire  available  equip¬ 
ment  in  satisfying  requirements. 

(2)  Message  Reproduction  and  Distribution. 

(a)  The  Navy  has  pursued  the  development 
of  a  message  reproduction  and  distribution  system  to  satisfy 
automation  of  the  manpower  intensive  functions  associated  with 
dissemination  of  message  traffic.  The  program  supporting  the 
Navy  requirements  is  the  Message  Routing  and  Distribution 
System  (MRDIS) .  A  total  of  fourteen  systems  have  been 
identified  for  application. 

(b)  The  JCS  is  implementing  a  large  scale 
reproduction  and  distribution  system,  in  conjunction  with  the 
consolidation  of  the  Pentagon  telecommunications  centers, 
using  Xerox's  Automated  Reproduction  Collating  System  (ARCS). 

(c)  The  Department  of  State  ARCS  program 
for  automated  message  distribution  has  been  evaluated  by  the 
Services.  It  was  determined  that  the  cost  effectiveness  of 
the  ARCS  would  limit  its  application  within  the  DoD  unless 
applied  to  extremely  large  telecommunication  centers. 

As  technology  advances,  however,  the  cost  effectiveness  of 
automating  message  handling  functions  using  a  similar  concept 
as  the  ARCS  would  permit  its  widespread  application. 

4.  Implementation  Alternatives .  Three  alternative 
approaches  to  providing  terminal  equipment  are  analyzed. 

The  objective  of  this  analysis  is  to  aid  in  reducing  the 
terminal  program  proliferation  and  aid  in  enhancing  the 
opportunity  to  achieve  maximum  standardization  with  increased 
cost  effectiveness. 

a.  Alternative  1.  Continue  Service/Agency  independent 
terminal  program  developments  until  the  common  family  of  terminals 
is  available.  Current  terminal  program  developments  do  not 
require  inter-Service/Agency  coordination .  This  course  of 
action  provides  the  Services/Agencies  independence  in  defining 
equipment  capabilities,  particularly  software.  The  equipment 
made  available  from  independently  managed  programs  is  unique, 
in  that  it  is  tailored  specifically  to  meet  the  managing  DoD 
components  requirements.  Software  independence  permits  the 
Services/Agencies  to  operate  efficiently  with  procedural 
requirements  achieved  through  software  programming.  With 
the  availability  of  the  common  family  of  terminals,  the 
Services/Agencies  would  be  required  to  develop  program  support 
for  implementation  of  this  equipment. 

(1)  Advantages.  The  Services/Agencies  can 
tailor  equipment  capabilities  to  closely  match  terminal 
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requirements  promoting  efficient  communications  center 
operations  in  view  of  current  procedural  practices.  State- 
of-the-art  advantages  can  be  realized  by  the  Services/ Agencies 
through  program  development,  including  these  features. 

(2)  Disadvantages.  This  course  of  action  will 
continue  proliferation  of  terminal  equipment  within  the  DoD. 

By  tailoring  equipment  for  unique  requirements,  progress 
towards  achieving  standardization  between  the  Services/Agencies 
would  continue  to  be  difficult  and  would  contribute  to 
excessive  expenditure  of  funds. 

b.  Alternative  2.  Withhold  approval  for  all  new 
terminal  programs;  permit  current  programs  to  continue  until 
the  common  family  of  terminals  is  available.  There  are 
sufficient  programs  within  the  DoD  to  satisfy  projected 
requirements  for  terminal  equipment  until  such  time  as  the 
common  family  of  terminals  is  available.  Therefore,  no  new 
programs  should  be  needed.  Unforeseen  requirements  would 
be  satisfied  using  available  terminal  equipments.  This 
approach  reinforces  the  standardization  of  the  terminal 
environment  by  requiring  the  Services/Agencies  to  use  only 
equipment  now  available,  which  in  some  cases  may  force  the 
user  to  adopt  different  Service/Agency  procedures. 
Standardization  of  procedures  is  the  key  to  an  integrated 
AUTODIN  system  and  is  covered  in  detail  under  Special  Items. 

The  results  of  the  standardization  effort  will  be  most 
effective  when  applied  to  a  stable  communications  terminal 
program  environment.  With  the  availability  of  the 
common  family  of  terminals,  the  Services/Agencies  would  be 
required  to  develop  program  support  for  implementation  of 
this  capability. 

(1)  Advantages.  By  requiring  the  Services/ 
Agencies  to  use  available  equipment,  the  move  towards 

a  standardized  DoD  communications  system  would  be  greatly 
enhanced.  The  absence  of  new  programs  would  reduce 
terminal  program  proliferation,  and  would  aid  the  DoD 
movement  towards  interoperability  within  the  DCS. 

(2)  Disadvantages.  Unforeseen  new  terminal 
requirements  would  be  dependent  upon  current  technology 
and  available  equipments.  Therefore,  the  Services/Agencies 
would  no  longer  have  the  flexibility  to  tailor  new  equipment 
to  specific  needs.  Also,  the  Services/Agencies  would  not 

be  able  to  apply  state-of-the-art  advances  in  terminal  equip¬ 
ment,  depriving  them  of  the  advantages  therein. 


c.  Alternative  3.  New  terminal  program  approval 
subject  to  OSD/JCS  review/coordination/concurrence;  continue 
current  terminal  programs  until  the  common  family  of  termi¬ 
nals  is  available.  The  need  for  additional  programs 
contingent  upon  critical  unforeseen  operational  requirements 
that  cannot  be  cost  effectively  satisfied  by  current  programs 
may  require  the  Services/Agencies  to  develop  new  terminal 
programs.  The  use  of  OSD/JCS  involvement  is  twofold.  OSD 
can  serve  as  the  focal  point  for  DoD  application  of  equipment 
developed  from  an  additional  program,  ensuring  interoperability 
considerations  are  implanted  in  the  program,  and,  in  the 
event  a  program  exists  unknown  to  the  requiring  DoD  com¬ 
ponent,  reduce  the  probability  of  terminal  program  prolifera¬ 
tion.  JCS  involvement  ensures  all  DoD  component  participation 
in  the  development  process.  Allowing  current  programs  to 
continue  until  expiration  serves  the  same  purpose  towards 
standardization  as  listed  in  Alternative  2.  Upon  development 
of  the  functional  specification  for  the  common  family  of 
terminals  in  August  1979  and  its  implementation  in  1983,  the 
terminal  environment  will  be  stable. 

(1)  Advantages.  DoD  coordination  in  the  develop¬ 
ment  of  new  programs  effectively  reduces  independent  program 
development  and  insures  wider  application  of  available  equipment 
When  new  requirements  arise  which  cannot  be  satisfied  by 
available  equipment,  they  would  be  developed  as  a  DoD 

program  rather  than  the  individual  Service/Agency  programs. 

An  example  of  this  in  action  would  be  the  development  of  the 
TTY  requirement  outlined  in  a  recent  Army  ROC.  All  three 
Services  have  expressed  interest  in  the  development  and 
procurement  of  new  TTY  equipment,  however,  independent 
procurement  paths  are  being  pursued.  An  OSD/JCS  role  would 
ensure  there  would  be  one  standardized  system  based  upon 
functional  specifications  rather  than  separate  programs. 

(2)  Disadvantages.  The  Services/Agencies  would 
no  longer  have  the  flexibility  to  pursue  tailored  equipment 
to  meet  terminal  requirements. 

d.  Conclusions. 

(1)  Alternative  1  offers  little  potential  for 
promoting  standardization  and  halting  proliferation  of  terminal 
equipment.  The  advantage  of  tailoring  terminal  equipment  to 
satisfy  Service/Agency  requirements  needs  to  bo  balanced  against 
the  costs  associated  with  maintaining  separate  programs 

and  the  impact  on  DoD  terminal  standardization. 

(2)  Alternative  2  provides  the  foundation  for 
moving  the  IAS  architecture  towards  standardization,  but 
limits  the  Services/Agencies  flexibility  in  satisfying  un¬ 
foreseen,  justifiable  requirements. 
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(3)  Alternative  3  provides  for  OSD/JCS  concurrence 
on  any  new  Service/Agency  terminal  programs  until  the  functional 
specif ications for  a  common  family  of  terminals  is  available  in 
August  1979.  This  alternative  provides  the  means  to  satisfy  new 
requirements  in  an  orderly  manner,  with  a  reduction  in  the  risk 
of  terminal  proliferation  and  program  duplication.  It  also 
provides,  in  the  near  term,  a  solid  foundation  for  the 
standardization  of  terminal  procedures  and  equipments. 

e.  Recommendation.  Alternative  3  be  selected  as  the 
implementation  alternative  for  terminals. 

E.  Special  Items. 

1.  Standards .  Within  the  IASA,  standards  take  many  forms. 

They  deal  with  the  sophisticated  protocols,  interfaces,  modes 
of  operation,  formats,  controls,  management,  equipment  designs 
and  capabilities,  as  well  as  the  micro-functions  of  what 
information  is  required  for  record  keeping  to  determine 
proper  handling  of  a  message.  Standards  are  required  to 
provide  uniform  guidance  for  the  design,  development  and 
implementation  of  any  evolving  future  system.  Providing  these 
standards  for  guidance  from  the  concept  engineering  stage  to 
the  implementation  stage  will  help  to  reduce  design  ineffi¬ 
ciencies  and  reduce  overall  costs  as  well  as  prevent  inter¬ 
operability  problems  during  or  after  implementation.  Further, 
standards  establish  a  reference  source  of  design  guidance 
that  will:  (1)  minimize  unilateral  design  decisions  by  one 
project  engineering  group;  (2)  pinpoint  areas  wher<;  design 
decisions  are  needed;  (3)  facilitate  the  comparison  and 
evaluation  of  design  criteria  in  regard  to  trade-offs  and 
impact  on  other  subsystems  and  overall  system  performance; 
and  (4)  provide  wider  exposure  of  design  decisions  to  all 
interested  activities.  As  a  result  a  standard  for  Long  Haul 
Communications  Switching  Planning  Standards  for  the  Defense 
Communications  System,  Military  Standard  187-310,  has  been 
developed.  It  covers  such  issues  as  subsystem  interfaces, 
computer  software,  precedence  handling,  speed  of  service, 
minimize,  formats,  link  protocols,  and  mode  protocols.  The 
following  is  a  discussion  of  unresolved  issues: 

a.  Message  Forms.  A  study  was  made  of  the  present 
DD  Form  173  (OCR) ,  JOINT  MESSAGEFORM,  and  discovered  that 
there  are  three  such  forms  in  existence.  Each  Military 
Department  has  in  some  manner  made  small  deviations  from  the 
basic  standard  provided  in  MIL-STD- 1 88C.  It  was  also 
discovered  that  each  Military  Department  was  programming 
their  OCR  equipment  to  conform  to  either  Military  Department 
or  local  requirements  in  the  preparation  and  reading  of  the 
"standard"  form.  It  was  further  noted  that  the  printing  of  the 
form  in  an  unauthorized  drop-out  color  was  being  accomplished. 

To  provide  a  standard  for  the  Department  of  Defense  use  the 
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three  forms  were  compared  and  a  revised  form  was  developed. 

The  form  was  updated  to  include  additional  information  to 
include  new  requirements  of  the  system  such  as  the  using 
of  a  Special  Category  designator  to  ensure  U.S.  traffic 
would  not  be  inadvertently  sent  over  an  allied  line.  At 
the  same  time  revised  instructions  for  the  completion  of 
the  form  were  prepared.  The  recommended  revised  form  and 
preparation  instructions  were  provided  the  DCA  representa¬ 
tive  of  the  Methods  and  Procedures  Panel  of  the  MCEB  for 

that  board's  approval,  implementation,  and  inclusion  in  the 
appropriate  Military  Standard.  Unless  strong  resistance 
to  standardization  is  met  in  the  MCEB  arena,  no  further 
action  on  this  item  is  contemplated  under  the  IASA  project. 

b.  Addressing  and  Routing  Traffic  Procedures. 

For  years  each  Military  Department  has  had  their  own  standard 
plain  language  address  for  their  subordinate  organizations 
and  had  these  published  in  their  service  publication.  On 
9  June  1975,  the  MCEB  issued  a  directive  to  establish  a 
Standardized  Plain  Language  Address  System.  In  an  attempt 
to  standardize  Plain  Language  Addresses  (PLAs)  a  first 
effort  was  made  to  standardize  abbreviations,  geographic 
locations,  etc.  Due  to  Service/Agency  parochialism  this 
obstacle  could  not  be  overcome.  Rather  than  standardize 
elements  of  the  PLA  it  was  agreed  that  the  term  "standard 
PLA"  would  be  construed  to  mean  "a  single  way  of  addressing 
a  particular  command  or  activity  as  determined  by  the 
responsible  service  or  DoD  agency."  Because  of  the  magnitude 
and  impact  of  this  action  item,  it  was  briefed  at  the 
Principals'  meeting  in  May  1975  for  resolution  of  the 
problem.  A  two  step  approach  was  established.  Step  one 
was  for  DCA  to  prepare  and  distribute  a  DoD  PLAD  and  the 
Services  would  continue  to  use  their  PLA  documents.  The 
DoD  PLAD  would  be  distributed  to  Service  elements  for 
review  and  comments  as  to  its  feasibility.  If  the  DoD  PLAD 
concept  is  acceptable,  the  second  step  would  be  taken  to 
publish  a  single  DoD  PLAD.  DCA,  in  concert  with  the  MCEB 
prepared  a  DoD  PLAD  consisting  of  DoD  agencies  and  commands, 
as  well  as  other  Federal  Government  agencies  that  fall  under 
the  auspices  of  the  National  Communications  System  and  use 
DoD  communications  facilities.  The  final  decision  of  the 
MCEB  was  to  prepare  the  document  as  a  MCEB  document  rather 
than  a  DCA  publication.  The  document  was  completed,  dis¬ 
tributed,  and  the  effective  date  of  1  July  1977  was  promulgated. 
A  six  month  review  period  was  established  as  part  of  the 
Principals'  guidance.  The  Department  of  Air  Force  requested 
a  three  month  extension  of  the  evaluation  period  due  to  some 
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internal  distribution  problems.  This  will  extend  the  final 
action  of  step  one  by  the  MCEB  to  approximately  June  1978. 
Routing  of  traffic  within  AUTODIN  I  will  continue  to  be  by 
Routing  Indicator  as  prescribed  by  ACP  117  and  supplements 
thereto.  AUTODIN  II  will  use  a  logical  address  located  in 
the  packet  header  as  supplied  by  the  bit-oriented  subscriber 
or  by  the  interface  device  for  character  oriented  subscribers 

c.  Automated  Distribution  System/Methods.  On  27  May 
1973,  the  MCEB  issued  a  directive  for  the  development  of  a 
standard  message  delivery  system.  To  get  an  unbiased  look 
at  the  problem,  a  study  contract  was  awarded  KETRON,  Inc., 
on  15  July  1975.  This  study  was  provided  the  MCEB  on  11 
December  1975.  The  MCEB  reviewed  the  study  and  presented  a 
briefing  to  the  Principals  on  29  June  1976  with  recommendations 
that  the  study  be  forwarded  to  the  JCS  for  review  by  the 
administrative  people  as  they  would  become  involved  with 
whatever  system  is  implemented.  The  JCS  requested  the 
Services,  DC A,  DIA,  and  NSA  review  the  Ketron  study  and 
provide  their  comments.  On  12  April  1977,  JCS  opened  a  joint 
action  on  this  subject.  The  JCS  action  was  completed  in 
December  1977.  Its  recommendation  to  the  MCEB  is  that  a 
standardized  content  code  applied  by  the  message  writer  is  not 
supported  by  the  JCS,  however,  scanning  techniques  which 
permit  the  use  of  plain  language  cues  such  as  flagwords, 
functional  address  and  office  codes,  keyphrases,  reference 
and  report  types  could  be  supported  but  would  have  to  be 
tailored  to  meet  variable  requirements  of  telecommunication 
centers . 


d.  Privacy  Considerations.  In  AUTODIN  I,  the  AUTODIN 
Limited  Privacy  System  (ALPS)  provides  the  level  of  privacy 
required  by  not  recording  traffic  on  history  tapes  within  the 
ASC.  In  addition  to  message  security  protection  provided  by 
security  markings  of  the  message,  a  Transmission  Control  Code 
(TCC)  is  included  in  AUTODIN  II  to  identify  a  community-ot_ 
interest.  Each  TCC  is  a  unique  and  separate  code  that  does 
not  have  dependency  or  another  TCC  or  security  classification 
code  or  designator.  To  enter  a  specific  network  or  terminal, 
verification  of  the  TCC  is  made  by  the  system  prior  to  trans¬ 
mission  of  the  data  to  the  terminal.  In  addition  codes  may 
be  included  in  the  Host  Level  Protocol.  To  ensure  privacy 
and  security  is  maintained,  both  the  originating  and  receiving 
terminals  must  be  classmurkod  in  the  PSN  software  for  entry 
and  receipt  of.  the  TCC  being  used. 
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e.  Telecommunications  Center  Manning  Standards. 

With  the  implementation  of  telecommunications  center 
automation,  the  Services/Agencies  have  pursued  the  develop¬ 
ment  of  manning  standards.  The  following  identifies  progress 
by  the  various  DoD  components  towards  adopting  manning 
standards  for  automated  telecommunications  centers: 

(1)  Army.  The  Army  has  completed  a  preliminary 
staffing  study  and  data  gathering.  A  staffing  standard  is 
undergoing  development  and  should  be  available  in  the  near 
future  (April-May  1978) . 

(2)  Navy.  The  Navy  has  completed  data  gathering 
and  is  expecting  to  complete  a  draft  standard  in  April  1978. 

A  scheduled  sixty  (60)  day  review  period,  during  which  the 
Navy  expects  to  provide  opportunity  for  command  review,  will 
immediately  follow  rough  draft  preparation.  Navy-wide 
implementation  of  the  standard  is  expected  as  of  1  October 
1978. 


(3)  Air  Force.  Air  Force  has  completed 
preparation  of  an  automated  communications  center  staffing 
document  and  is  awaiting  Service  staffing  prior  to  implementa¬ 
tion. 


(4)  NSA .  As  of  26  September  1977,  NSA  has 
instituted  a  communications  staffing  standard  for  all  their 
telecommunications  centers. 

(5)  DIA.  DIA  is  using  the  NSA  developed  standard. 

(6)  DLA .  DLA  manning  of  automated  telecommuni¬ 
cation  centers  is  position-oriented  due  to  the  unique  nature 
of  traffic  transmitted  and  received.  Consequently,  a  de  facto 
standard  exists  for  their  communications  centers.  Adoption 

of  a  DoD  standard  pertaining  to  narrative  traffic  would  not 
affect  their  communications  center  operations. 

The  DCA  has  formed  a  working  group  to  address  the  development 
of  a  DoD  standard  manning  document  for  telecommunications 
center  manning. 

2 .  DSSCS/GENSE R  Telecommunications  Center  Consolidation 
and  Extension  of  Automation. 


a.  Prior  to  1973,  DSSCS  and  GENSER  record  traffic  was 
processed  within  physically  distinct  communications  networks. 
In  Julv  1972,  an  AUTODIN  I  system  enhancement  was  provided 
which  permitted  use  of  the  AUTODIN  I  to  handle  both  DSSCS  and 
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GENSER  traffic.  Both  DSSCS  and  GENSER  were  maintained  in  a 
segregated  environment,  with  terminals  designated  as 
either  DSSCS  or  GENSER,  but  not  both.  Thus,  AUTODIN  I  was 
operated  as  if  it  consisted  of  two  virtual  networks,  each  of 
which  operated  in  a  system  high  security  mode,  without  mutual 
interface.  Thus,  separate  DSSCS  and  GENSER  terminal  facilities 
are  installed  at  most  major  military  installations. 

b.  In  1976,  AUTODIN  I  was  enhanced  to  permit  a  single 
connected  terminal  to  transmit  and  receive  both  DSSCS  and 
GENSER  record  traffic.  The  connected  terminal  is  required  to 
operate  in  a  DSSCS  accredited  environment.  This  enhancement 
allows  physical  consolidation  of  DSSCS  and  GENSER  terminal 
facilities  at  a  geographic  location.  Such  physical  consolida¬ 
tion  offers  the  potential  for  cost  and  manpower  savings.  In 
recognition  of  this  potential,  the  DoD  telecommunications 
community  has  identified  139  locations  which  exhibit  sufficient 
potential  as  to  warrant  a  consolidation  feasibility  study. 
Feasibility  study  completion  dates  from  February  1978  through 
September  1978  have  been  established  by  JCS.  Thus,  a  program 
to  provide  intra-Service  physical  consolidation  of  DSSCS/GENSER 
facilities  within  a  local  geographic  area  is  well  underway. 

The  IASA  will  accordingly  be  required  to  accommodate  a  smaller 
number  of  terminal  connections.  AMPE  facilities  now  being 
fielded  provide  extension  of  automated  services  to  connected 
remote  terminals.  Currently,  only  the  NSA  AMPE,  the  STREAM¬ 
LINER,  has  been  accredited  to  process  DSSCS  traffic;  the 
STREAMLINER,  as  well  as  connected  remote  terminals,  may  process 
DSSCS  traffic.  A  connected  remote  terminal  may  operate  as  a 
DSSCS  or  a  DSSCS/GENSER  terminal;  it  may  not,  however, 
operate  as  a  GENSER-only  remote  terminal .  The  Army  and  Navy 
are  pursuing  PSSCS  accreditation  for  their  AMPE  facilities, 
while  the  Air  Force  is  considering  so  doing.  An  accredited 
automated  terminal  must  conform  to  the  stringent  criteria 
jointly  developed  by  NSA  and  DIA,  and  shortly  to  be  released 
as  a  DoD  Manual.  Accreditation  of  AMPE  facilities  permitting 
connected  DSSCS  remote  terminals  will  result  in  reduced 
direct  terminal  connectivity  to  the  IASA  backbone.  Estab¬ 
lishing  accreditation  in  a  system  high  mode  of  operation, 
i.e.,  all  connected  remote  terminals  conforming  to  DSSCS 
criteria,  is  a  much  less  severe  problem  than  that  posed  by 
connection  of  a  GENSER-only  remote  terminal.  Software 
routines  and  hardware  modifications  permitted  the  AUTODIN  I 
system  to  handle  both  DSSCS  and  GENSER  traffic,  while  main¬ 
taining  proper  traffic  segregation.  Terminal  users  con¬ 
nected  to  the  AUTODIN  system  are  unable  to  access  AUTODIN 
system  software.  Some  users  are  connected  to  AMPEs  via 
inquiry  response  terminal  devices  which,  in  the  absence  of 
proper  safeguards,  could  be  used  to  assault  the  system. 
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c.  The  previously  mentioned  DoD  Manual  will  provide 
guidelines  which  must  be  met  for  accreditation  of  an  AMPE  with 
connected  DSSCS  and  GENSER-only  remote  terminals.  NSA  is 
conducting  an  internal  study  to  determine  the  modifications 
required  to  obtain  such  accreditation  for  the  STREAMLINER. 

Both  consolidation  and  extension  of  automation  require  a 
solution  to  the  multi-level  security  problem.  AUTODIN  I 
solved  the  problem  by  operation  in  a  system-high  environment, 
and  by  hardware/software  segregation  in  a  relatively  benign 
environment.  The  recent  Report  of  the  Ad  Hoc  Working  Group 
for  ATMHS  Review  concluded  that,  without  resolution  of  the 
Multi-Level  Security  problem,  parallel  systems  development  and 
installation  would  continue.  The  Working  Group  recommended 
that  NSA  be  tasked  to  evaluate  near  term  alternatives  to  the 
Multi-Level  Security  objective.  Such  an  evaluation  would 
produce  an  acceptable  interim  standard  solution. 

d.  Major  R&D  resources  are  currently  committed  to 
the  relatively  long-term  BLACKER  program,  which  will  provide 
an  end-to-end  encryption  solution  to  the  network  multi-level 
security  objective. 

3.  Baseline  Allocation  of  Functions. 

a.  General.  As  part  of  the  IASA  project  design 
baseline  data  base  gathering,  seventy-four  (74)  telecommuni¬ 
cations  functions  now  performed  within  or  considered  candidates 
for  performance  within  AUTODIN  have  been  identified  and 
defined.  In  addition,  the  functions  have  been  tentatively 
allocated  to  the  elements  of  a  postulated  1980  architecture 
(Figure  4),  consisting  of  terminals  and  nodal  facilities, 

with  an  AUTODIN  II  backbone. 

b.  Allocation  Scheme.  Appendix  3,  Part  1,  provides 
the  baseline  allocation  of  telecommunication  functions  per¬ 
ceived  to  be  required  in  the  near  term  1978-83  IAS.  In 
addition,  Part  2  of  Appendix  3  provides  a  priority  listing 
of  the  telecommunications  functions  which  establishes  the 
criteria  for  future  decision  making  in  view  of  potential 
economic  constraints  on  the  allocation  of  these  functions. 
Underway  is  an  AMPE  Phase  III  cost/benefit  analysis  study, 
the  results  of  which  will  aid  in  the  cost  analysis  on  the 
remaining  telecommunications  functions. 

4.  ARPANET  connectivity  to  AUTODIN  II. 

a.  General.  The  ARPANET  came  under  the  operational 
management  of  DCA  on  1  July  1975.  DTACCS  approval  of  AUTODIN 
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II*  Phase  I  indicated  that  the  Military  Department/Defense 
Agency  ADP  systems  on  the  ARPANET  should  configure  their 
design  so  as  to  minimize  the  impact  of  reconnecting  to  the 
AUTODIN  II.  The  results  of  a  recently  completed  survey  of 
ARPANET  subscribers  are: 

(1)  The  ARPANET  is  an  operational,  common 
user,  data  communications  network,  not  an  R&D  network. 

(2)  The  ARPANET  is  divided  into  servers  and 
users.  Server  hosts  are  mostly  government  owned  and  are 
located  at  universities  and  corporations.  Users  are  on 
the  network  primarily  to  access  the  server. 

(3)  The  ARPANET  community  of  interest  is  an  inter¬ 
woven  conglomeration.  The  ARPANET  provides  capabilities  for 
interaction  between  all  its  users,  and  in  practice,  the 
intercommunication  between  military  and  non  military  users 

is  significant.  The  transition  must  provide  for  continuing 
intercommunication  between  the  users. 

(4)  DARPA  uses  the  ARPANET  for  backbone  com¬ 
munications  for  some  existing  R&D  efforts. 

(5)  The  ARPANET  can  provide  transmission 
security  from  host  to  host. 

b.  Implementing  Alternatives. 

(1)  Alternative  1.  Continue  to  operate  the 
existing  ARPANET. 

(a)  Advantage:  Maintains  the  status  quo. 

(b)  Disadvantages: 

JL.  The  ARPANET,  a  first  generation 
packet  switching  network,  has  aging  equipment  and  maintenance 
costs  which  will  become  prohibitive  within  another  3  years. 

2.  Ignores  intent  of  OSD  that  AUTODIN 
II  serve  general  DoD  ADP  systems  as  well  as  military  operational 
systems . 

(2)  Alternative  2.  DCA  continue  to  operate  the 
ARPANET  for  an  additional  3  years.  Identify  and  transition 
selected  users  to  AUTODIN  II. 
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(a)  Advantages:  Continue  operational 
management  and  existing  network  as  is. 

(b)  Disadvantages: 

1.  Availability  of  AUTODIN  II  protocols 
and  interface  control  criteria.  ARPANET  hosts  or  nodes  will 
have  to  access  AUTODIN  II  using  the  Binary  Segment  Leader 
(Mode  VI  type)  protocols.  These  protocols  are  due  from  the 
AUTODIN  II  contractor  in  August  1978.  ARPANET  nodes  and/or 
hosts  must  develop  their  own  Host  Specific  Interface. 

2_.  Leaves  unanswered  the  question  of 
what  to  do  with  the  users  not  transferring  to  AUTODIN  II. 

2-  Requires  an  R&D  effort  to  determine 
method  of  providing  intercommunication.  This  effort  would  be 
of  limited  value  upon  demise  of  the  ARPANET. 

(3)  Alternative  3.  DCA  contract  with  a  Value- 
Added  Carrier  (VAC)  to  take  over  comm unications  services 
provided  by  the  ARPANET: 


(a)  Advantages: 

1^.  Provides  a  continuing  communications 
vehicle  for  users  not  transitioning  to  AUTODIN  II. 


to  AUTODIN  II. 


2.  VAC  could  develop  the  interface 


2-  VAC  would  provide  conversion  to 
X25  interface  (the  international  standard) . 


(b)  Disadvantage:  As  cost  competitiveness 
accrues  from  volume  discounts,  the  government  may  be  required 
to  continue  in  a  management  capacity  pertaining  to  the  contract. 

c.  Analysis. 

(1)  Alternative  1  maintains  the  existing 
ARPANET  and  ignores  the  cost  advantages  of  transitioning 
ARPANET  users  to  the  AUTODIN  II. 
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(2)  Alternative  2  continues  the  ARPANET  for 
a  period  of  time  while  transitioning  some  subscribers  to 
AUTODIN  II.  Information  presently  available  indicates  that 
ARPANET  DoD  subscribers  have  a  continuing  communications 
requirement  with  non-DoD  and  non-government  ARPANET  sub¬ 
scribers.  This  requires  some  method  of  providing  a  con¬ 
tinuing  communications  capability  for  any  existing  ARPANET 
subscriber  transferred  to  AUTODIN  II  with  hosts  left  on  the 
residual  ARPANET.  The  most  feasible  way  to  provide  this 
capability  is  via  a  gateway.  The  gateway  concept  will  push 
the  state-of-the-art,  and  will  also  cause  security  certifi¬ 
cation  concern. 

(3)  Alternative  3  assumes  contracting  the 
communications  functions  for  the  ARPANET  to  a  VAC.  There 
is  some  indication  that  a  VAC  would  bid  a  three  year 
contract  to  provide  the  ARPANET  communications  at  a  lesser 
cost  than  presently  being  experienced.  Included  could  be 
design  and  implementation  of  a  gateway  between  the  VAC  and 
AUTODIN  II  and  access  to  the  international  carriers  by 
conversion  to  the  X25  interface.  A  BTL  could  accrue  for 
the  three  year  period  and  reduce  to  zero  at  the  end  of  the 
three  year  period. 

(4)  Approach.  ARPANET  connectivity  to  AUTODIN 
II  will  begin  in  late  1980  and  be  completed  in  1982. 

All  desiring  ARPANET  users  who  can  satisfy  the  criteria 
of  JCS  MOP  165  will  be  transferred  to  AUTODIN  II.  Government 
packet  switching  R&D  users,  which  comprise  a  small  percentage 
of  the  net,  will  be  provided  service  through  other  government 
sponsored  programs.  The  larger  percentage  of  current 
ARPANET  users  will  be  transferred  to  a  Value  Added  Network 
(VAN)  and  a  gateway  of  the  VAN  to  AUTODIN  II,  if  required, 
will  be  provided. 

5.  WIN  Integration  into  AUTODIN  II 

a.  General.  Memorandum  by  ASD/CCCI,  7  October 
1977,  subject:  "Prototype  WWMCCS  Intercomputer  Network 
(PWIN) , "  directed  that  a  plan  for  the  implementation  of 
WWMCCS  internetting  be  developed.  The  JCS  is  preparing  a 
WIN  Implementation  Plan  that  provides,  in  part,  the  transition 
of  the  WIN  to  AUTODIN  II. 
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b.  Network  Evaluation.  In  accordance  with  the 
draft  WIN  Implementation  Plan,  the  PWIN  will  be  redesignated 
as  the  WIN  on  1  April  1978.  The  1977  PWIN  of  6  IMPS  and  6 
Hosts  will  evolve  into  the  1980  WIN  of  10  IMPS  and  21  Hosts. 

The  transfer  of  WIN  sites  to  AUTODIN  II  subscribers  will 
begin  in  mid-1980  when  the  prototype  WWMCCS  ADP  Network  Front 
End  (WNFE )  is  first  available,  and  will  be  completed  in  1983 
when  the  fully  capable  Network  Front  End  (NFE)  is  available. 
Refer  to  Table  9.  The  WIN  Implementation  Plan, 

in  part,  will  provide  the  goals  and  objectives  of  the  network 
and  will  propose  a  three  phase  approach  which  identifies 
management  requirements,  network  configurations,  milestone 
schedule,  resource  (manpower/funding)  requirements,  and 
transition  to  AUTODIN  II.  The  plan  conceives  the  implementa¬ 
tion  to  be  spread  over  three  phases.  It  will  transform  the 
existing  prototype  network  into  an  operational  system.  The 
first  phase  is  designed  to  be  a  period  in  which  the  network 
gradual  transitions  and  expands  from  a  prototype  network  to 
an  operational  capability.  During  the  first  phase,  the 
number  of  network  subscribers  will  be  expanded;  procedures 
and  policies  for  network  operation  refined;  studies  and 
analyses  to  expand  and  enhance  network  applications  and 
information  exchange  conducted;  new  network  management  and 
coordination  agencies  activated.  In  Phase  II  the  network  will 
provide  full  support  to  the  WWMCCS.  WIN  Phase  II  will  begin 
with  the  cutover  to  WWMCCS  System  Release  7.1,  projected  for 
January  1979,  and  will  end  with  the  cutover  to  the  AUTODIN  II. 
During  Phase  II  the  communications  related  capabilities  of  the 
network  will  remain  essentially  stable,  but  the  user  applica¬ 
tions  reporting  systems  and  procedures  will  continue  to  be 
improved.  Technical  plans  for  interfacing  the  WWMCCS  computers 
into  AUTODIN  II  and  managerial  plans  for  the  conversions  to 
AUTODIN  II  support  will  be  completed  during  this  phase.  WIN 
Phase  III  begins  with  the  cutover  of  the  WWMCCS  computers  to 
AUTODIN  II  communications  support.  Expansion  and  improvement 
of  network  oriented  user  applications  and  reporting  systems, 
and  procedures  will  also  be  accomplished  during  this  period. 

c.  Transition  Issues.  During  the  initial  two  phases 
the  host  computers  will  be  interconnected  by  a  dedicated  com¬ 
munications  subnet  employing  the  WWMCCS  adaption  of  a  packet 
switching  technology  based  on  the  PWIN  program.  During  Phase 
III  the  communications  support  will  be  provided  by  AUTODIN  II. 
For  the  period  prior  to  AUTODIN  II  support,  the  WIN  will  be 
configured  to  support  those  WWMCCS  commands  which  have 
responsibilities  in  time  sensitive  crisis  situations.  The 
WIN  will  be  transferred  to  AUTODIN  II  support  when  it  is 
established  that  AUTODIN  II  is  capable  of  providing  the 
interactive  capabilities  needed  by  the  WWMCCS. 
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plan  identifies  the  AUTODIN  II  conversion  plans  to  be 
developed  and  assigns  responsibility  for  their  development. 
During  Phase  III  the  WIN  will  receive  packet  switching 
support  from  the  AUTODIN  II  common  user  system.  The  inter¬ 
connection  of  the  WWMCCS  computers  to  the  AUTODIN  II  will 
require  special  hardware  and  software  in  order  to  achieve  a 
full  interactive  capability.  Each  host  will  function  as 
network  front  end.  Th3  WWMCCS  network  front  end  will  be 
connected  to  the  AUTODIN  II  packet  switch  nodes  via  at  least 
one  data  circuit. 


TABLE  9 


PWIN/WIN/AUTODIN  II  TRANSITION 


PHASE  III 

PHASE  I(PWIN)  PHASE  II (WIN)  (AUTODIN  II) 

1977  1978  1979  1980/81  1982/83 

IMPS  6  9  10  10 

Hosts  6  12  19  21 

Concentrators  1  1  1 

Terminals  11  13  12  11 

DIN  II 

Subscribers  25 

6.  Tactical  Forces.  Interface  of  tactical  forces  to 
the  DCS  will  be  via  the  TRI-TAC  AN/TYC-39  Store-and-Forward 
(S&F)  Module.  The  AN/TYC-39  was  initially  envisioned  as 
serving  both  a  tactical  and  a  strategic  function.  In  its 
tactical  role,  it  would  interface  with  AUTODIN  as  a  Mode  I 
terminal.  In  its  strategic  role,  it  would  serve  as  an  A SC. 
Advancements  in  technology,  AUTODIN  software  enhancements 
not  incorporated  into  TYC-39  software,  increased  costs,  and 
changes  in  the  hardware  capability  of  the  TYC-39  combined 
to  eliminate  the  TYC-39  as  a  viable  candidate  for  direct 
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ASC  replacement.  The  tactical  role  of  the  AN/TYC-39  remains 
valid.  Deployment  of  the  AN/TYC-39  as  a  message  switch  in 
the  forward  area,  will  provide  primary  DCS  interoperability 
for  tactical  forces. 

7 .  Automated  Text  Message  Handling  Systems  (ATMHS) . 

a.  General.  On  25  March  1977,  the  Surveys  and 
Investigations  (S&I)  Staff  of  the  House  Appropriations 
Committee  (HAC)  published  a  report  highly  critical  of  DoD 
management  citing  lack  of  standardization  and  duplication  of 
effort  in  ATMH  Systems  development.  An  Ad  Hoc  Working  Group 
for  ATMH  Systems  review,  chaired  by  DCA  and  composed  of 
representatives  from  the  Services  and  Defense  Agencies,  was 
formed  on  18  November  1977  and  completed  its  report  on  13 
December  1977.  The  report  will  be  forwarded  by  the  JCS  to 
ASD/CCCI.  The  report  categorizes  ATMH  Systems  as  tele¬ 
communications  oriented  (concerned  with  message  transmission 
and  distribution)  and  information  oriented  (concerned  with 
message  content) .  The  report  evaluated  10  telecommunications 
oriented  and  12  information  oriented  ATMHS. 

b.  Analysis.  The  ATMHS  report  concludes  that 
functional  standardization  and  operational  validation  of 
telecommunications  oriented  ATMH  Systems  are  being  adequately 
addressed  within  the  IASA  project,  but  that  functional 
standardization  and  operational  validation  of  information 
oriented  ATMH  Systems  are  not  being  comprehensively  addressed. 
Therefore,  the  report  recommends  DCA  as  Project  Manager  to 
establish  an  IASA-like  program  to  provide  functional  standardi¬ 
zation  and  operational  validation  for  information  oriented 
ATMHS . 

8 .  Billing  Structure. 

a.  DCA,  assisted  by  the  Institute  for  Defense  Analysis 
(IDA) ,  has  examined  various  rate  structure  alternatives  for  the 
AUTODIN  I  and  AUTODIN  II.  Current  plans  call  for  continuation 
of  the  present  rate  structure  for  AUTODIN  I  through  FY  1979. 
This  structure  is  based  solely  on  connectivity  and  speed  of 
service.  Beginning  in  FY  1980,  plans  are  to  implement  a 
revised  billing  structure  for  AUTODIN  I  based  on  connectivity 
and  use.  ASD(C)  approval  of  the  revised  structure  will  be 
requested  as  part  of  the  FY  1980  CSIF  Budget  Submission. 
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b.  The  following  schedule  of  events  apply  to  the 
AUTODIN  II  rate  structure: 

(1)  Prior  to  the  AUTODIN  II  Phase  I  FOC  during 
FY  1980,  the  current  weighted  unit  billing  structure,  based 
on  the  speed  of  service,  will  be  used. 

(2)  During  FY  1980,  sufficient  traffic  and 
use  experience  data  should  be  available  for  FY  1981 
implementation  of  a  connectivity/use  bi31inq  structure. 

ASD(C)  approval  will  be  requested  during  the  CSIF  FY  1981 
Budget  Submission  during  the  September  1979  time  period. 

(3)  Based  on  study  results,  present  estimates 
are  that  approximately  twenty  percent  of  the  backbone  cost 
will  be  based  on  connectivity  and  eighty  percent  based  on 
use  (number  of  packets  transmitted) . 

(4)  The  subscriber  rate  for  AUTODIN  II  will  be 
developed  based  on  the  concept  that  the  majority  of  revenue 
collected  by  the  CSIF  should  be  based  on  network  use  and 
that  rates  should  encourage  the  precedence  qualified  users 
to  eliminate  unnecessary  precedence  traffic.  The  rationale 
for  emphasizing  use  is  primarily  to  enhance  cost  discipline 

of  requirements  and  to  match  system  capability  to  user  require¬ 
ments.  A  fundamental  principle  applied  during  design  of  this 
system  was  to  develop  a  network  that  could  be  sized  to  fit  the 
user  requirements.  (This  design  principle  has  been  achieved 
but  its  effectiveness  depends  in  part,  on  a  rate  .structure 
that  will  influence  usage,  hence  the  size  of  the  network.) 

Use  not  only  applies  to  how  much  traffic  (packets)  is  generated, 
but  also  the  precedence,  distance  and  geographical  locations 
of  the  traffic.  Since  all  will  affect  the  network  size,  thev 
will  be  considered  during  the  rate  development  process.  Traffic 
volume,  however,  will  be  the  major  factor  used  in  determining 
the  size  of  the  switches  and  the  number  of  trunks  required. 

9 .  Security . 

a.  General.  Recent  trends  in  teleprocessing  technology 
are  producing  changes  in  the  user  security  environment.  More 
and  more,  teleprocessing  capability  is  being  extended  to  lower 
levels  of  communications  and  will  eventually  evolve  to  the  level 
of  individual  action  officers  (i.e.,  collocated  with  action 
office)  .  Thus,  not  only  will  interactive  ADP-type  communications 
capabilities  become  proliferated,  but  the  equipments  to  be  used 


will  be  in  office  environments  incapable  of  providing  the 
physical  protection  traditionally  afforded  COMSEC  equipments. 
Numerous  system  interconnections  with  many  communities  of 
users  will  increase  the  need  for  access  control  mechanisms 
to  restrict  authorized  use  of  files,  programs,  and  other  ADP 
resources,  whether  accidental  or  malicious. 

b.  Architectural  Considerations.  The  following 
security  techniques  will  be  considered  in  the  architectural 
development: 


(1)  Prepositioned  user  access  criteria  and 
traffic  acceptance  criteria  within  the  network  switches 
integrated  with  the  automatic  routing  routines  in  order 
to  provide  security  constraints  on  traffic  flow. 

(2)  Validating  subscriber  access  and  notifying 
traffic  recipient  of  the  sender's  identification  (terminal 
authentication) . 

(3)  Providing  distinct  separation  of  communities 
of  interest  within  the  common  user  network  .  This  would 
protect  against  unauthorized  access,  provide  a  form  of 
authentication,  and  protect  against  communications  systems 
mistakes . 


(4)  Employment  of  certifiable  and  validated 
security  controllers  as  a  part  of  the  ADP  communications 
processor  as  a  means  to  control  unclassified  subscriber 
access  to  the  multilevel  network,  establish  and  validate 
user  security  credentials  and  communicate  same  to  destination 
ADP  system. 


(5)  Employment  of  automatic  remote  cryptographic 
keying  and  key  distribution  centers  in  conjunction  with 
network  procedures  for  isolation  of  communities  of  interest, 
authentication,  etc. 

(6)  Employment  of  traffic  flow  security  on  all 
sensitive  DoD  communication  circuits. 

(7)  Employment  of  off-line  encryption  by  a  user 
community  to  preencrypt  traffic  destined  for  common  user 
bases  where  security  segregation  and/or  privacy  must  be 
maintained.  Data  stored  in  the  common  data  base  would  remain 
in  the  encrypted  form.  Of  course,  certain  labels  on  the  files 
would  have  to  remain  in  plain-text  to  facilitate  automatic 
file  search. 
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(8)  Employment  of  personnel  security  badges  that 
would  provide  authentication  of  personnel  assigned  to  a 
multilevel  security  access  terminal. 

(9)  Employment  of  security  kernel  technology  to 
facilitate  formal  verification  of  software  development. 

(10)  The  long-range  IASA  security  architecture 
objective  is  to  meet  the  multilevel-security  issue  via 
end-to-end  encrypted  data  communications.  A  supporting  RDT&E 
program  will  apply  the  encryption  devices  being  developed  in 
the  NSA  Blacker  prototype  end-to-end  encryption  program, 

the  protocols  and  communications  trade-offs  being  developed 
in  the  ARPA  end-to-end  encryption  experiment,  and  the  DCA 
(CCTC)  secure  network  front-end  development.  Products  of 
this  effort  will  include  the  system  concepts,  key  generator 
hardware  and  the  controlling  software  for  the  encryption  of 
packet  switched  data.  The  Blacker  program,  using  selected 
test  beds,  will  yield  production  key  generators  in  the  1983 
time  frame. 
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SECTION  IV 


TRANSITION  STRATEGY 


A .  Achieving  Evolutionary  Transition . 

1.  General .  ASD(C3I)  quidance  to  the  Defense  Communi¬ 
cations  Agency  (DCA)  has  been  to  achieve  the  IAS  in  an 
evolutionary  manner;  i.e.,  by  a  deliberate,  continuous 
change  from  today's  communications  to  the  more  sophisticated 
communications  of  the  future.  Several  technology  advances 
have  been  noted  which  will  have  impact  on  this  changing 
environment.  Communications  systems  are  evolving  in  such  a 
way  that  centralized  management  and  automated  control  with 
nunimal  human  intervention  are  becoming  cost-effective. 

In  addition,  the  IAS  is  not  a  single  monolithic  system  which 
will  "cutover"  at  a  specified  "IOC  date".  Instead  it  will 
grow  incrementally  into  a  complex,  but  unified,  DCS  sub¬ 
system  during  the  period  1978  to  circa  1990,  with  multiple 
IOC  dates  during  that  period  for  the  various  IAS  elements 
with  concurrent  phase-out  of  obsolete  elements.  The  plan¬ 
ning  of  a  smooth  transition  over  that  time  interval  is  one 
of  the  most  important  aspects  of  the  architectural  strategy. 
The  following  time  periods  have  been  assigned  to  the  various 
parts  of  the  IASA  project; 

a.  Near  Term;  1978-1983. 

(1)  Deployment  of  AUTODIN  II  packet  switches 
in  CONUS  and  to  a  limited  extent  overseas. 

(2)  Thinning  of  AUTODIN  I  switch 

population. 

(3)  Complete  deployment  of  the  current 
generation  of  AMPEs  by  1982  with  further  access  area 
needs  provided  by  an  Inter-Service/Agency  AMPE ,  which 
can  serve  all  DoD  users  in  an  area  and  interface  either 
AUTODIN  I  or  AUTODIN  II  switches. 

(4)  Deployment  of  a  common  family  of  AUTODIN 
terminals  based  upon  functional  specifications. 
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b.  Mid  term:  1984-1988. 

(1)  Further  deployment  of  AUTODIN  II  switches 

overseas. 

(2)  Phase-out  of  AUTODIN  I  switches. 

(3)  Provision  for  AUTODIN  I  unique  functions 
in  either  an  augmented  Interservice/Agency  AMPE  or  a 
Centralized  Service  Facility  associated  with  AUTODIN  II 
nodes  or  both. 


c.  Far  term:  1989-Future.  A  third  generation 

data  system  to  be  defined  in  conjunction  with  the  other  third 
generation  subsystems  of  the  DCS. 

Viewed  in  this  way  the  near  term  IAS  can  be  looked  at  as 
an  early  DCS  II  capability  which  attempts  to  solve  the  termi¬ 
nal  proliferation  problem.  The  mid  term  system  becomes 
a  DCS  II  subsystem  and  the  far  term  system  a  DCS  III  sub¬ 
system. 


2.  Architectural  Development  Works.  The  near  term 
1978-1983,  IAS  architecture  has  been  described  in  Section 
III,  however,  the  mid  and  far  term  IAS  architecture  has 
not  yet  been  developed  or  selected.  DCA  has  started  the 
development  of  this  architecture  and  two  IAS  architectures 
are  postulated  and  evaluated  for  implementation.  The 
description  of  these  two  architectures,  the  identification 
of  required  major  network  hardware  elements  and  the 
identification  of  near  term  transitional  commonalities  are 
presented. 


a.  Terrestrial  Switched  Architecture.  This 
architecture  is  basically  an  extension  of  the  near  term 
architecture  and  its  functional  elements  are  present  in 
the  circa  1990  architecture,  although  some  elements  have 
changed  physically.  The  technological  risk  associated  with 
this  architecture  is  minimal  because  of  its  heavy  reliance 
on  the  proven  designs  employed  in  the  1980  architecture. 

The  terrestrial  switched  architecture,  depicted  in  Figure 
8,  has  been  divided  into  the  following  levels: 

(1)  Backbone.  The  backbone  will  have  highly 
interconnected  PSNs  centrally  managed  by  a  Network  Control 
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Legend 


G  -  Gateway 

CSF  -  Centralized  Service  Facility 
PSN  -  Packet-Switch  Node 
M  -  Multiplexer 

T  -  Terminal  {Source/Destination  of  Traffic) 

T  -  Specialized  Subscriber 

a 

Tg  -  Slow  Speed  Subscriber 

T^  -  Host  Computer  >1 

LRAN  -  Local/Regional  Access  Node 

-  -  Packet  Backbone  Trunks  (up  to  Tl  Carrier) 

_  -  Access  Lines  (150  bps  to  greater  than  56  kbps) 


Footnotes 

1.  The  CSF  while  planned  for  the  backbone  could  also  be 
located  in  the  regional  access  area. 

2.  It  is  anticipated  that  the  LRAN  will  be  implemented 
using  standardized  modules  (both  hardware  and  software)  plus 
some  special  modules  depending  on  site  requirements.  Also 
there  may  be  significant  differences  between  the  local 

and  regional  LRANs  in  amount  of  processing  power  and  the 
quantity  and  type  of  terminations. 


Figure  8 .  Continued 


Center  (NCC)  with  centralized  network  problem  solving  by 
a  Software  and  Hardware  Test  Facility  for  both  CON  IS  and 
overseas.  In  addition  to  the  PSNs,  the  backbone  will  have 
Centralized  Service  Facilities  (CSFs)  and  Gateways. 

(a)  Definitions.  The  CSF  is  a  new 
network  element  required  to  provide  and  enhance  those 
services  previously  provided  by  the  AUTODIN  I.  This  new 
element  is  postulated  to  be  a  computer  facility  connected 
as  a  host  computer  to  a  PSN  or  to  a  regional  node.  The 
CSF  would  have  considerable  processing  power  combined  with 
extensive  memory  in  several  media  (e.g.,  core,  fixed  disc 
and  dismountable  disc) .  The  CSF  will  provide  certain 
message  processing  services  (e.g. ,  multiple  and  collective 
address  handling,  intercept  and  message  retrieval)  and  any 
new  teleprocessing  services  (e.g. ,  electronic  mail  service, 
data  teleconferencing  and  word  processing) .  The  gateway 
will  provide  the  IAS  with  a  means  to  interface  other  digital 
data  networks  such  as  special-purpose  military  and 
commercial  Value  Added  Networks.  This  will  provide  for 
interoperability  among  data  networks. 

(b)  Approach.  The  exact  implementation 
has  not  yet  been  determined,  however,  architectural  alterna¬ 
tives  and  recommendations  will  be  provided  in  the  January 
1979  IASA  report.  A  probable  implementation  would  be  as 
unique  software  modules  in  conjunction  with  standard 
hardware  and  software  modules.  (It  is  anticipated  that  a 
common  family  of  functional  modules  will  be  used  by 
terminals,  access  nodes  and  PSNs,  as  well  as  by  the  CSF 

and  Gateway) .  The  circa  1990  PSN,  like  the  1980  PSN,  will 
be  essentially  identical  to  that  of  the  AUTODIN  II  Phase  I. 
As  such  it  will  be  modular  in  both  hardware  and  software 
such  that  individual  nodes  can  expand  and  contract  with 
changes  in  their  terminations  and  traffic  volume.  The 
circa  1990  IAS  will  have  end-to-end  encryption  capabilities. 
To  support  this  capability,  the  backbone  will  also  contain 
Key  Distribution  Center (s)  (KDCs)  to  control  end-to-end 
encryption  and  to  distribute  a  variable  to  the  crypto¬ 
graphic  algorithm  at  the  originating  and  terminating  user 
terminals . 


(2)  Access  Area  (Local  and  Regional) . 


(a)  Definition.  The  Local/Regional  Access 
Node  (LRAN)  is  postulated  as  an  extension  program  to  the 
Inter-Service/Agency  AMPE,  with  a  modularly-expandable  multi- 
microprocessor  architecture  in  the  far  term  (DCS  III) 
environment.  The  architecture  of  the  far  term  IAS  is 
expected  to  allocate  certain  functions  to  communications 
nodal  facilities  located  at  the  local  and  regional  access 
area  levels.  While  the  architectural  description  which 

will  specify  the  functional  performance  requirements  of 
these  nodal  facilities  is  not  yet  available,  one  can 
infer  the  expected  nature  of  some,  if  not  most  of  their 
functions  by  reference  to  today's  ASCs  and  the  AMPEs.  These 
faculties  will  perform  the  broad  range  of  nodal  functions 
plus  local  message  distribution  functions  and  provide 
numerous  services  (such  as  plain  language  addressing)  which, 
in  a  different  architecture,  might  well  be  allocated  to  a 
different  element.  On  the  other  hand,  functions  not 
performed  by  ASCs  and  Inter-Service/Agency  AMPEs  may  also 
be  allocated  to  the  Local  Regional  Access  Node  (LRAN) .  It 
is  anticipated  that  the  regional  version  of  the  LRAN  will 
have,  in  addition  to  its  ASc/AMPE  like  functions,  packet 
switching  and  packet  interface  capabilities.  Thus,  the 
terrestrial  architecture  trunking  will  be  able  to  extend 
to  the  regional  level,  and  for  the  satellite  architecture, 
the  LRAN,  when  combined  with  a  ground  station,  will  be  able 
to  handle  the  packet  broadcast  mode  of  operation. 

(b)  Approach.  The  regional  access  area 
will  have  packet  LRANs  and  multiplexers.  The  LRAN  will 
probably  be  connected  to  two  PSNs  and  to  other  packet 
LRANs  while  the  multiplexer  will  be  connected  to  a  single 
PSN  or  possibly  a  packet  LRAN.  The  packet  LRAN  will  have 
packet  trunks  to  the  PSNs  and  othe r  packet  LRANs.  In  the 
local  access  area  there  will  be  smaller  LRANs  serving 
geographical  groups  of  subscribers.  These  local-level  LRANs 
will  be  connected  to  either  regional  packets  or  PSNs.  In 
addition  to  LRANs,  local-level  multiplexers  will  be  used 
where  transmission  economies  can  be  effected.  While  no 
lateral  interconnection  of  local  LRANs  is  anticipated, 
exceptions  will  be  considered  on  a  case- by-case  basis.  The 
local  access  area  will  contain  a  wide  variety  of  terminals 
ranging  from  low-speed  type  terminals  up  through  sophisticated 
host  computer  facilities. 


-86- 


F/«  17/2 


DEFENSE  COMMUNICATIONS  A6ENCY  ARLINGTON  V A 

INTEGRATED  AUTODIN  SYSTEM  ARCHITECTURE  REPORT.  PART  l.CU) 

DEC  77 


(3)  Development.  Significant  DCA  and  Service/ 
Agency  Research  and  Development  will  be  required  for  the 
functional  specifications  of  a  common  family  of  hardware 
and  software  modules.  It  is  envisioned  that  the  common 
hardware  modules  would  be  procured  to  a  specification 
which  would  stipulate  their  form,  fit  and  function,  but 
not  the  details  of  implementation.  Included  in  the 
hardware  complement  would  be  processing,  storage  and  I/O 
interface  modules.  In  addition,  effort  will  be  required 
for  the  LRAN,  CSF,  Gateway  and  PSN  to  develop  those  unique 
hardware  or  software  modules  required  for  specific 
configurations.  In  order  to  enhance  and  complement  the 
thrust  to  standardize  computer  software,  a  high  order 
communications  oriented  language  (COL)  is  needed.  Also 
the  conversion  from  total  reliance  on  link-by-link  to 
primary  reliance  on  end-to-end  security  will  require  exten¬ 
sive,  closely  coordinated  RDT&E  effort.  Reference  is  made 
to  Table  10  for  a  summary  of  IAS  RDT&E  funds  for  the 
period  FY  1977  -  1984. 

b.  Broadcast  Satellite  Architecture. 

Today,  communications  satellites  are  in  general  use  for 
both  DoD  and  commercial  communications.  Domestic 
commercial  satellites,  international  communications 
satellites  over  the  Atlantic,  Pacific,  and  Indian  Oceans 
and  DSCS  and  NATO  satellites  are  all  being  used  as  an 
alternative  to  cable,  microwave,  troposcatter ,  and  HF 
for  obtaining  point-to-point  connectivity.  Commercial 
satellite  services  for  the  most  part,  are  presently  priced 
to  compete  with  similar  commercial  services  (cable),  but 
eventually  they  are  expected  to  be  reduced  in  price.  All 
of  the  above  mentioned  satellites  operate  in  the  same 
manner;  namely,  they  provide  a  circuit  between  any  two 
points.  In  each  case  the  circuit  is  dedicated 
and  acts  as  a  replacement  for  a  terrestrial  link.  The 
nature  of  the  satellite  is  such  that  any  signal  beamed 
down  is  readable  by  any  earth  station  equipped  to  receive 
the  wideband  transponder's  signal  and  demultiplex  it. 

This  inate  ability  has  the  potential  to  be  the  driving 
force  towards  a  new  DCS  architecture.  In  this  broadcast 
satellite  system,  transponder  capacity  on  the  satellite 
is  available  to  users  via  the  regional  oacket  LRANs. 

The  regional  LRANs  will  be  equipped  with  a  satellite  ground 
station.  These  LRAN/ground  stations  will  time  their 
transmissions  (which  are  wideband  signals,  up  to  the 
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capacity  of  the  transponder)  so  as  not  to  interfere  with 
each  other.  Use  of  the  "up  channel"  will  be  broken  into 
time  or  frequency  slots,  each  slot  being  used  by  a 
ground  station  to  transmit  the  data  the  LRAN  has 
accumulated  from  its  input  users.  The  techniques  of 
managing  ground  station  transmissions  vary  from  simple 
contention  methods  to  complex  conflict-free  multiple  access 
protocols.  It  is  envisioned  that  some  technique  will  be 
employed  such  that  the  satellite  resource  will  be  adjusted 
by  controlled  allocation.  Interconnection  of  the  regional 
LRANs  in  this  manner  would  effectively  provide  a  fully 
connected  network.  Figure  9  depicts  the  broadcast 
satellite  architecture  which  has  been  divided  into  the 
following  levels: 

(1)  Backbone. 

The  backbone  will  consist  of  sufficient  broadcast  satellite 
transponder  capacity  to  provide  global  coverage. 

(2)  Access  Area  (Local  and  Regional) . 

The  regional  access  area  will  have  packet  LRANs  and 
multiplexers.  Each  regional  LRAN  will  have  a  satellite 
ground  station  associated  with  it.  There  will  probably 
be  some  terrestrial  interconnection  between  regional 
LRANs,  dependent  on  geographical  location  and  traffic 
volume.  Some  LRANs  will  have  CSFS  and/or  Gateways  associated 
with  them.  Some  limited  capability  will  exist  in  the 
regional  packet  LRAN  to  reconstitute  a  terrestrial  switched 
network  by  calling  up  the  necessary  terrestrial  communica¬ 
tions  media.  The  multiplexers  and  the  local  LRANs  will  be  connected 
to  the  regional  LRAN.  In  the  local  access  area  there 

will  be  smaller  LRANs  serving  tight  geographical  groups  of 
subscribers.  In  addition  to  LRANs,  local- level  multiplexer 
will  be  used  where  transmission  economies  can  be  effected. 

While  no  lateral  interconnection  of  local  LRANs  is 
anticipated,  exceptions  will  be  considered  on  a  case-by- 
case  basis.  The  local  access  area  will  contain  a  wide 
variety  of  terminals  ranging  from  low-speed  terminals  up 
through  sophisticated  host  computer  facilities. 

(3)  Development. 

While  significant  difort  will  be  required  for  the  development 
of  the  common  hardware  and  software  modules  for  the  unique  modules 
for  the  LRAN,  CSF  and  Gateway,  and  for  the  end-to-end  security 
subsystem,  these  developments  are  identical  to  those 
described  in  2a  (3)  above.  On  the  other  hand,  development 
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Footnotes 

1.  This  CSF  is  the  same  CSF  postulated  for  the  Terrestrial 
Switched  Architecture. 

2.  This  gateway  is  the  same  gateway  postulated  for  the 
Terrestrial  Architecture. 

3.  Similarly  the  multiplexers  and  terminals  are  the  same  as 
those  postulated  for  the  Terrestrial  Architecture. 

4.  Note  the  regional  LRAN  is  depicted  with  an  antenna  to 
indicate  that  a  satellite  ground  station  is  associated  with 
the  LRAN.  Also  note  that  some  terrestrial  packet  trunks  will 
probably  exist,  dependent  on  geography,  traffic  volume  between 
pair  of  nodes,  need  for  backup,  etc. 

5.  The  local  LRAN  is  the  same  as  that  postulated  for  the 
Terrestrial  Switched  Architecture. 

6.  Both  local  and  regional  LRANs  will  be  implemented  using  the 
common  family  of  hardware  and  software  modules  and  unique 
modules  as  required. 

7.  The  significant  difference  between  the  two  candidate 
architectures  is  in  the  backbone  area,  the  satellite  archi¬ 
tecture  provides  only  the  transmission  medium,  the  satellite. 
However,  the  satellite  allows  for  full  interconnection  of  the 
nodes  which  access  it. 


Figure  9.  Continued 
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of  satellite  ground  stations  and  the  algorithm  for 
accessing  the  satellite  is  a  major  requirement  unique  to 
the  satellite  architecture.  Significant  RDT&E  effort  to 
support  this  requirement  has  been  planned  under  the 
Experimental  Integrated  Switched  Network  (EISN)  project. 

c.  Outlook  for  the  far  term,  circa  1990,  IAS. 

It  is  reasonable  to  assume  that  the  far  term  IAS  will 
not  be  identical  to  either  of  the  networks  described  in 
paragraphs  2a  and  2b.  The  terrestrial  switched  architecture 
ignores  the  advancing  state-of-the-art  in  satellite  and 
communications  technologies  and  the  implications  of  distance, 
available  media  bandwidth  and  cost  of  O&M  for  backbone 
nodes  and  communications  media.  The  satellite  architecture 
ignores  the  available  and  in  place  CONUS  media  facilities 
and  considerable  investment  in  PSNs,  inter-Service/Agency 
AMPEs,  and  other  facilities.  Further,  neither  architecture 
appears  to  take  into  account  the  vast  difference  in  geo¬ 
graphy  and  political  situations  of  the  three  locales  of 
the  global  DCS  -  Europe,  CONUS,  and  the  Pacific.  Other 
satellite  access  methods,  using  a  terrestrial  backup  net¬ 
work  to  supplement  and  complement  the  satellite  capability, 
are  possible  and  the  existence  of  a  restoral  capability  for 
the  DCS  is  a  survivability  requirement.  Two  types  of  LRANs 
are  envisioned  in  these  architectures.  One  is  a  regional 
version  capable  of  operating  as  a  packet  switching  node  in 
direct  communication  with  the  packet  broadcast  satellite 
via  the  collocated  satellite  ground  station.  As  such  it 
provides  backbone,  regional,  and  local  nodal  functions,  as 
well  as  ground  station  functions  for  the  satellite.  The 
second  type  of  LRAN  is  a  local  version  which  would  not  have 
direct  access  to  the  satellite.  This  LRAN  provides  the  func¬ 
tions  required  at  the  local  level.  It  is  connected  to  a 
packet  LRAN  to  gain  access  to  the  backbone  satellite.  Both 
LRANs  are  implemented  using  the  common  family  of  hardware  and 
software  modules  plus  any  unique  modules  required.  The 
modular  aspects  of  the  LRAN  should  reduce  maintenance  costs 
and  allow  greater  flexibility  in  sizing  the  stations,  and 
would  afford  the  potential  of  providing  the  capability  of 
doing  some  of  the  CSF  functions  locally  if  required  or 
desired  by  conditions.  Note  that  the  two  architectures 
have  numerous  features  in  common;  i.e.,  local  and  regional 
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LRANSs,  local  and  regional  multiplexers,  CSFs,  gateways 
and  the  same  array  of  subscribers.  Therefore,  it  is 
possible  to  proceed  with  confidence  on  an  RDT&E  program 
to  develop  the  required  modules.  Moreover.,  the  far 
term  IAS  could  be  a  hybrid  solution  combining  aspects 
of  several  possible  solutions;  further,  it  is  possible 
that  each  of  the  three  locales--Europe,  CONUS,  and  the 
Pacif ic--will  have  different  sub-architectures. 

B.  Analysis . 

1.  Approaches .  The  terrestrial  and  satellite  candidate 
backbone  architectures  stated  above,  while  differing  widely  in 
final  approach,  proceed  initially  from  the  near  term 
1978-1983  system  architecture  (presented  in  Section  III) 

in  the  same  manner.  Further,  in  the  access  area,  the 
similarities  in  the  near  term  are  more  significant  than 
the  differences.  Transition  approaches,  which  do  not 
proceed  initially  from  the  near  term  IASA,  could  have 
been  postulated.  However,  such  approaches  would  not 
be  consistent  with  evolutionary  transition  and  the 
efficient  use  of  R&D  resources.  As  the  mid  and  far 
term  architecture  development  of  the  IAS  proceeds,  the 
LRAN ,  CSF ,  and  gateway  concepts  may  be  altered  from 
what  has  been  postulated. 

2.  Timeline.  Figure  10  provides  the  IASA  transition 
strategy  for  the  period  1978  to  1990.  The  near  term,  1978- 
1983,  strategy  shown  in  Figure  10  has  been  explained,  by 
item,  within  Section  III  of  this  report.  In  addition. 

Tables  11  and  12  provide  lists,  respectively,  of  backbone 
and  access  area  activities  along  with  associated  target 
dates  in  chronological  order.  Architectural  development 
results  for  the  mid  term  (1934-1988)  and  the  far  term 
(1339-future)  IAS  will  be  provided  in  the  IASA  Project  Part 
2  report,  due  January  1979. 
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TABLE  11 


r 


AUTODIN  BACKBONE  MILESTONES 

ACTIVITY  CY  TARGET  DATE 


a. 

Overseas  (O/S)  ASC  Memory  Upgrade 

1978 

b. 

CONUS  ASC  Tape  Replacement  by  Disc 

1978 

c. 

Phase  OUt  one  PAC  Area  ASC 

1978 

d. 

IOC  AUTODIN  II  Phase  I 

1979 

e. 

Start  Phase  Out  CONUS  ASCs 

Rehome  Affected  Subscribers 

1980 

f . 

O/S  ASC  Tape,  Card  Reader  and  Printer 
Replacement;  Upgrade  of  Patch  and  Test 
Facilities 

1980 

g. 

Complete  Fielding  AUTODIN  II 

Phase  I  (four  PSNs) 

1980 

h. 

O/S  AUTODIN  II  Multiplexers 

1980 

i. 

Start  CONUS  AUTODIN  II  Expansion 

1981 

j  • 

CSF  Specifications  and  SOW  Prepared 

1982 

k. 

CSF  Contract  Award 

1983 

1. 

Complete  CONUS  AUTODIN  II  Expansion 
(eight  PSNs) 

1983 

m. 

Complete  Phase  Out  up  to  four  CONUS 

ASCs 

1983 

n. 

Start  Fielding  O/S  PSNs 

1983 

o. 

Start  Fielding  Gateways  (as  needed) 

1983 

P- 

Start  Fielding  CSFs 

1985 

q. 

Start  Phase  Out  Remaining  ASCs 

Rehome  Affected  Subscribers 

1985 

l 

I 
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TABLE  11  (CONT) 

ACTIVITY  CY  TARGET  DATE 

r.  Start  Fielding  End-to-End  Security  1986 

s.  Complete  Fielding  O/S  PSNs  1987 

t.  Complete  Fielding  Overseas  CSFs  1987 

u.  Complete  Phase  Out  Overseas  ASCs  1987 

v.  Complete  Phase  Out  DIN  I  ASC  CONUS  1988 

w.  ipomplete  Fielding  CONUS  CSFs  1988 

x.  Complete  Fielding  End-to-End  Security  1990 


i 
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TABLE  12 


AUTODIN  ACCESS  AREA  MILESTONES 

ACTIVITY 

CY  ‘ 

TARGET  DATE 

a. 

Field  AMPEs 

In 

progress 

b. 

Start  Fielding  SRTs 

1978 

c. 

Functional  Specifications  for  Common 

1979 

Family  of  Terminals 

a. 

Baseline  Established 

1980 

e. 

Inter-Service /Agency  AMPE  SOW/RFP 

1980 

f. 

Inter-Service/Agency  AMPE  Contract 

1981 

g. 

Complete  Fielding  AMPEs 

1982  , 

h. 

Complete  Fielding  SRTs 

1982 

i. 

Start  Fielding  Inter-Service /Agency  AMPEs 

1983 

j. 

Start  Fielding  New  Generation  Terminals 

1983 

k. 

Start  Fielding  End-to-End  Security 

1986 

1. 

LRAN  SOW/RFP 

1988 

m. 

Field  Evaluate  Broadcast  Satellite  -  Pacific 

1989 

Europe 

1990 

CONUS 

1990 

n. 

Start  Fielding  LRANs 

1990 

o. 

Start  Voice/Data  Integration  Pilot  Demonstration 

1990 

P- 

Complete  Fielding  End-to-End  Security 

1990 
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SECTION  V 


CONCLUSIONS  AND  RECOMMENDATIONS 


A.  Conclusions . 


1.  The  previous  sections  to  this  IASA  project  report 
have  presented  a  picture  of  the  AUTODIN  system  from  the 
perspective  of  near  term  (1978-1983)  implementation 
alternatives  and  mid/far  term  (1984-1990)  architectural 
alternatives.  Based  upon  user  requirements  and  the  need 
to  provide  more  efficient  common-user  AUTODIN  service,  a 
transition  strategy  has  been  provided  from  today's 
AUTODIN  capabilities  to  the  circa  1990  Integrated  AUTODIN 
System. 

2.  The  overall  objective  of  the  IASA  project  is  to 
design  and  engineer  a  system  based  upon  AUTODIN  I  and 
AUTODIN  II,  which  is  complete  and  integrated  from  end 
to  end.  The  IASA  design  is  by  necessity  evolutionary 

in  development,  with  the  key  ingredient  being  responsiveness 
to  user  needs.  In  meeting  this  objective,  the  IASA  project 
has  logically  been  divided  into  three  parts.  This  report 
comprises  Part  1  of  the  IASA  effort  and  provides  AUTODIN 
implementation  alternatives  through  1983.  In  January  1979, 
Part  2,  architectural  alternatives  for  the  period  1984 
to  1990  will  be  provided.  In  August  1979,  Part  3,  the 
functional  specifications  for  a  common  family  of  terminals 
will  be  provided. 

3.  The  AUTODIN  terminal-to-terminal  analysis  has 
resulted  in  the  following  conclusions: 

a.  The  current  AUTODIN  I  store-and-f orward  system 
will  continue  to  provide  message  service  to  the  user 
community  through  at  least  1985. 

b.  Implementation  of  eight  CONUS  AUTODIN  II 
Packet  Switching  Nodes  will  make  it  feasible  to  close  up 
to  four  CONUS  AUTODIN  I  switching  centers. 

c.  Analysis  of  Services/Agencies  Automated  Message 
Processing  Exchanges  (AMPEs)  reveals  that  twenty-six  of 
thirty- two  evaluated  telecommunications  functions  have  a 
high  degree  of  commonality. 

d.  An  Inter-Servico/Agency  AMPE  program  is  viable. 
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e.  Some  AUTODIN  terminal  hardware  standardization 
exists  among  the  Services/Agencies,  but  there  is  very  little 
software  standardization. 

f.  There  are  multiple  AUTODIN  terminal  programs 
available  to  satisfy  the  Services/Agencies  requirements 
until  the  common  family  of  terminals  functional  specifi¬ 
cations  is  available. 

g.  The  Standard  Remote  Terminal  (SRT)  can  be 
applied  as  a  replacement  for  Digital  Subscriber  Terminal 
Equipment,  as  a  remote  terminal  to  an  AMPE ,  and  as  a 
replacement  for  comparable  automated  terminals.  On  the 
other  hand,  the  cost-effectiveness  of  the  SRT  as  compared 
with  other  available  terminal  equipment  will  limit  its 
application . 

h.  Physical  consolidation  of  Special  Intelligence 
and  General  Service  Telecommunications  Centers  will  provide 
significant  equipment  and  manpower  savings.. 

i.  Telecommunications  functions  have  been 
allocated  to  the  elements  of  an  IAS  Architecture  consisting 
of  terminals  and  nodal  facilities.  As  part  of  this 
functional  allocation,  a  priority  listing  of  seventy-f'*ur 
telecommunications  functions  has  been  developed  which 

will  aid  in  determining  what  system  capabilities  to 
provide  under  the  AUTODIN  architecture. 

j.  Security  in  the  near  term  (1978-1983)  time 
frame  will  be  provided  by  link  encryption.  Solutions  to 
i he  technical  problems  of  providing  AUTODIN  end-to-end 
encryption  will  be  dependent  on  such  efforts  as  the 

NS A  Blacker  project. 

k.  ARPANET  connectivity  to  AUTODIN  II  will 
start  in  1980  and  be  completed  during  1982. 

l.  WIN  integration  into  AUTODIN  II  will  start 
in  1980  and  be  completed  during  1983. 

m.  A  proposed  Standard  DD  Form  173  Joint  Message- 
form  with  a  proposed  method  of  completing  the  form  has 
been  developed  and  forwarded  to  the  Military  Communications 
Electronics  Board. 

n.  A  Joint  DoD  Plain  Language  Address  Directory  (PLAD) 
has  been  published,  and  is  under  evaluation  by  the  Services/ 
Agencies  to  determine  its  effectiveness  as  the  single  PLAD 

for  the  entire  DoD. 


B.  Recommendations. 


1.  As  a  result  of  efforts  to  identify,  correlate,  and 
project  the  Services/Agencies  AUTODIN  requirements  the 
following  recommendations  are  that: 

a.  An  Inter-Service/Agency  AMPE  program  replace 
the  current  AMPE  programs  by  1983. 

b.  Services/Agencies  continue  their  current  terminal 
programs  with  new  terminal  programs  subject  to  OSD/JCS 
concurrence  and  until  such  time  as  the  common  family  of  terminals 
is  available. 


c.  Services/Agencies  be  active  participants  in  the 
evaluation  of  selected  telecommunications  functions  for 
AMPE  standardization. 

d.  Services/Agencies  conduct  a  cost  analysis  of 
the  Standard  Remote  Terminal  (SRT)  versus  comparable 
terminal  equipme^*  to  determine  SRT  cost-effectiveness. 

e.  A  standard  message  delivery  system  be  developed 
for  AUTODIN  terminals  in  order  to  assist  in  developing  the 
functional  specifications  for  a  common  family  of  terminals. 

f.  A  uniform  staffing  standard  for  automated  and 
semi-automated  telecommunications  centers  (TCCs)  be  estab¬ 
lished. 


g.  A  revised  CSIF  billing  structure  based  upon 
connectivity  and  use  start  in  fiscal  year  1980  for  AUTODIN 
I  and  fiscal  year  1981  for  AUTODIN  II. 
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ADCCP 

ADU 

ALPS 

AMME 

AMPE 

ARCS 

ARPANET 

ASC 

ASCII 

ASD/C3I 

(ASD/CCCI) 

ATMHS 

ATP 

ATCAP 

AUTODIN 

C 

CARP 

CCU 

COL 

CONUS 

CPU 

CRC 

CCTC 


ACRONYMS 

-  Advanced  Data  Communications  Control  Procedures 

-  Accumulation  Distribution  Unit 

-  AUTODIN  Limited  Privacy  Service 

-  Automated  Multi-Media  Exchange 

-  Automated  Message  Processing  Exchange 

-  Automatic  Reproduction  Collocation  System 

-  Advanced  Research  Projects  Agency  Network 

-  AUTODIN  Switching  Center 

-  American  Standard  Code  for  Information 
Inter-Change 

-  Assistant  Secretary  of  Defense/Command 
Control  Communications  and  Intelligence 

-  Automated  Text  Message  Handling  System 

-  Automated  Telecommunications  Program 

-  Army  Telecommunications  Automation  Program 

-  Automatic  Digital  Network 

-  Contingency  Alternate  Routing  Plan 

-  Common  Control  Unit 

-  Communications  Oriented  (High  Order)  Language 

-  Continental  United  States 

-  Central  Processing  Unit 

-  Cyclic  Redundancy  Check 

-  Command  &  Control  Technical  Center 


CRITICOM 


CRITICOM 

-  Critical  Communications 

CRT 

-  Cathode  Ray  Tube 

CSF 

-  Centralized  Service  Facility 

CSIF 

-  Communications  Services  Industrial  Fund 

CSS 

-  Central  Security  Services 

D 

DARPA 

-  Defense  Advanced  Research  Projects  Agency 

DCA 

-  Defense  Communications  Agency 

DIA 

-  Defense  Intelligence  Agency 

DLA 

-  Defense  Logistics  Agency 

DoD 

-  Department  of  Defense 

DPI 

-  Data  Processing  Installation 

DSSCS 

-  Defense  Special  Security  Communications 

System 

DSTE 

-  Digital  Subscriber  Terminal  Equipment 

DTACCS 

-  Director  Telecommunications  and  Command 
Control  Communications  Systems 

and 

E 

ECP 

-  Engineering  Change  Proposal 

EIN 

-  Experimental  Integrated  Network 

EUCOM 

-  European  Command 

F 

FIPS 

-  Federal  Information  Processing  Standard 

FYP 

-  Five  Year  Plan 

G 

GAO 

-  Government  Accounting  Office 

GENSER 

-  General  Service 
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GFE 

H 

HSI 

I 

I/A 

IAS 

IASA 

ICATS 

IOC 

IRT 

J 

JCS 

K 

Kbits 

Kbs 

KDC 

L 

lb/s 

LDMX 

LRAN 

M 

Mbits 

MCCU 

MCEB 

MILDEPS 


1 

-  Government  Furnished  Equipment 

-  Host  Specific  Interface 

-  Interactive 

-  Integrated  AUTODIN  System 

-  Integrated  AUTODIN  System  Architecture 

-  Intermediate  Capacity  Automated  Telecommunica¬ 
tions  System 

-  Initial  Operational  Capability 

-  Interim  Remote  Terminal 

-  Joint  Chiefs  of  Staff 

-  Kilobits 

-  Kilobits  per  second 

-  Key  Distribution  Center 

-  Line  Block  per  Second 

-  Local  Digital  Message  Exchange 

-  Local-Regional  Access  Node 

-  Megabits 

-  Multiple  Channel  Control  Unit 

-  Military  Communications-Electronics  Board 

-  Military  Departments 
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MIL-STD 

MOP 

N 

NATO 

NAVCOMPARS 

NCC 

NPE 

NSA 

NTAP 

O 

OCR 

OCRE 

O/S 

OSD 

P 

PAC 

PACOM 

PLA-RI 

PLAD 

P/S 

PSN 

PWIN 

C 

Q/R 


-  Military  Standard 

-  Memorandum  of  Policy 

-  North  Atlantic  Treaty  Organization 

-  Naval  Communications  Processing  and  Routing 
System 

-  Network  Control  Center 

-  Network  Front  End 

-  National  Security  Agency 

-  Naval  Telecommunications  Automation  Program 

-  Optical  Character  Reader 

-  Optical  Character  Reader  Equipment 

-  Overseas 

-  Office  of  the  Secretary  of  Defense 

-  Pacific 

-  Pacific  Command 

-  Plain  Language  Addressing  -  Routing  Indicator 

-  Plain  Language  Address  Directory 

-  Packet  Switching 

-  Packet  Switch  Node 

-  Prototype  WWMCCS  Intercomputer  Network 

-  Query  Response 
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R&D 


RDT&E 

ROC 

S 

SCCU 

S&F 

SI 

SIGINT 

SPP 

SRT 

T 

TAM 

TARE 

TCC 

TTY 

U 

ULMS 

V 

VAC 

VAN 

VDU 

W 

WIN 

WNFE 


-  Research  and  Development 

-  Research  Development  Test  and  Evaluation 

-  Required  Operational  Capability 

-  Single  Channel  Control  Unit 

-  Store  and  Forward 

-  Special  Intelligence 

-  Signal  Intelligence 

-  Subsystem  Project  Plan 

-  Standard  Remote  Terminal 

-  Teletypewriter  Adapter  Module 

-  Teletypewriter  Automated  Relay  Equipment 

-  Transmission  Control  Code 

-  Teletypewriter 

-  Unit  Level  Message  Switch 

-  Value  Added  Carrier 

-  Value  Added  Network 

-  Video  Display  Unit 

-  WWMCCS  Intercomputer  Network 

-  WWMCCS  ADP  Network  Front  End 


WSEO 
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-  WWMCCS  System  Engineering  Organization 

-  World-wide  Military  Command  and  Control  System 


WWMCCS 
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k 


AMPE  PHASE  I/I I  ANALYSIS 


1.  This  appendix  includes  information  previously  published 
as  appendices  to  two  AMPE  comparison  studies: 

a.  Phase  1  -  Functional  Comparison  of  Automated  Message 
Processing  Exchanges,  14  October  1976. 

b.  Phase  2  -  Automated  Message  Processing  Exchange 
Functional  Comparison  Study  Phase  II,  18  November  1977. 

2.  Part  1  compares  the  manner  in  which  the  four  AMPEs  perform 
the  32  selected  functions,  and  also  contains  a  description  of 
the  physical  characteristics  of  the  AMPEs.  The  32  functions 
are  divided  into  three  categories: 

a.  AUTODIN  System  Requirements 

b.  Telecommunications  Center  Functions 

c.  Customer  Assistance  Functions 

3.  Part  2  of  this  appendix  is  a  technical  analysis  of 

the  32  functions  identified  in  Part  1.  The  analysis  is  based 
upon  detailed  data  submitted  by  the  Services/Agencies. 
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PART  2 


ANALYSIS  OF  FUNCTIONS 


1.  Constraints .  The  physical  comparison  charts  in  Part 
1  indicate  a  broad  range  of  processor  capabilities.  Three 
important  characteristics  are  shown: 

Throughput  7^-72  Line  Blocks/Second 

Terminal  capacity  16-255 remotes 

Storage  -  core  40K-512K  Bytes 

a.  The  ranges  of  throughput  and  storage  impose 
limitations  on  the  performance  of  the  selected  32  functions. 
The  functional  descriptions  of  reference  (a)  do  not  always 
consider  these  differences  in  characteristics.  As  an  example, 
smaller  STREAMLINERS,  with  storage  of  80K,  96K,  or  112K  bytes 
could  not  be  expected  to  perform  the  same  functions  in  the 
same  manner  as  an  AMME,  a  U  90/60,  or  an  ATP  5/6.  The  latter 
all  have  storage  up  to  256K  Bytes  storage  per  processor. 


b.  Another  constraint  is  the  cost  of  the  AMPEs .  The  costs 
tabulated  in  reference  (a)  show  that  system  costs  range  from 
OEbcnED)  STREAMLINERS  without  peripherals  are 

(DEIETED)  while  a  NAVCOMPARS  II  with  full  line  of  peripherals 
is  shown  as  (DELETED)  Again,  the  smaller  processors  at 
the  lower  prices  could  not  be  expected  to  perform  these  func¬ 
tions  equally  well  as  a  larger  processor  at  the  higher  end  of 
the  cost  range. 


2 .  AUTODIN 

System  Requirements. 

a . 

system: 

The 

following  functions  are  required  within  the  AUTODIN 

(1) 

Line  Protocol 

(2) 

Code  Conversion 

(3) 

Error  Checks  &  Correction 

(4) 

FIFO  by  Precedence 

(5) 

FLASH  and  Higher  Preemption 

(6) 

Multiple  Delivery  of  Single  Address  Messages 

(7) 

Media  Conversion 

(8) 

History  Logs  and  Files 
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b.  Since  all  AMPEs  perform  all  the  above  functions,  this 
analysis  is  keyed  on  the  exceptions  noted.  The  manner  of 
performance  varies  as  indicated. 

(1)  Line  Protocol .  All  AMPEs  are  standardized  in 
the  line  protocol  used  to  the  AUTODIN  ASC .  In  the  area  of 
line  protocol  to  terminals,  there  are  minor  differences.  All 
AMPEs  are  programmable  to  perform  a  variety  of  protocols. 

Current  usage  in  some  AMPEs  is  limited  to  a  few  protocols. 

There  are  no  major  obstacles  to  standardization  of  this  function 

(2)  Code  Conversion.  All  AMPEs  can  be  programmed  for 
any  required  code.  Each  AMPE  accepts  different  transmission 
codes,  and  thus  requires  different  code  conversions.  ATP  has 
numerous  conversions.  AMME  accepts  numerous  common  codes, 

and  prefers  to  use  a  single  transmission  code  to  terminals. 
STREAMLINER  accepts  ITA-2  or  ASC  II. 

(3)  Error  Checks  and  correction.  All  AMPEs  perform 
security  checks.  AMME  and  LDMX  check  the  same  types  of  error 
conditions.  STREAMLINER  performs  additional  security  checks, 
and  ATP  performs  all  required  AUTODIN  I  security  checks.  One 
unique  feature  was  noted  in  STREAMLINER,  where  the  "stutter" 
group  (QQQ)  signifies  end  of  classification  (stutter  group 
suppressed  on  output) . 

(4)  FIFO  by  Precedence.  LDMX  provides  function  on 
both  input  and  output,  maintaining  three  separate  queues. 

LDMX  provides  SI  to  GENSER  ratio  for  FLASH  messages.  Both 
STREAMLINER  and  LDMX  provide  FIFO  on  input  messages,  and 
provide  features  in  support  of  fleet  broadcast  function. 

ATP  processes  all  traffic  FIFO  by  precedence. 

(5)  FLASH  and  Higher  Preemption.  Preempted  messages 
are  restored  to  top  of  queue  in  AMME,  ATP,  and  STREAMLINER. 

The  STREAMLINER  identifies  that  acknowledgement  of  receipt 

to  FLASH  or  higher  precedence  messages  are  performed  within 
this  function.  All  perform  FLASH  overrides.  (See  para  f(6) 
below  -  Automatic  Service  Message  Generation) . 

( 6 )  Multiple  Delivery  of  Single  Address  Messages . 

The  capability  of  performing  this  function  is  dependent  upon 
the  AIG  file  size.  The  AIG  file  size  varies  from  200 
(expandable)  for  ATP,  up  to  32,000  for  LDMX.  The  number  of 
RIs  causing  multiple  .separate  messages  vary  from  500  in  AMME 
and  STREAMLINER  up  to  5,100  in  LDMX.  ATP  updates  AIG  auto¬ 
matically,  while  ir-REA-ILINFR,  AMME,  and  LDMX  update  in  the 
oackground  mode.  <  'OORI  is  a  procedure  limit  in  STREAMLINER; 

ATP  limited  only  ov  available  auxiliary  storage). 
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(7)  Media  Conversion.  This  function  depends  upon 
the  media  that  an  AMPE  uses.  AMME  offers  more  media  con¬ 
version  capabilities  than  others.  STREAMLINER  and  LDMX  offer 
lesser  conversions  than  AMME ,  and  ATP  offers  less  than  others, 
but  can  be  expanded.  STREAMLINER  currently  limited  to  card 
media,  but  plans  magnetic  tape  enhancement. 

(8)  History  Logs  and  Files.  The  manner  of  performance 
is  not  standardized.  The  storage  media  are  different.  The 
retention  times  are  not  standardized,  afid  variations  on  IAS 
from  6  hours  data  retention  in  AMME  to  15  day  retention  in  LDMX. 
All  AMPEs  record  history  tapes  for  longer  retention.  ATP 
enhancement  pljanned  will  provide  15  day  on  line  retention. 

'  t 

3 .  Telecommunications  Center  Requirements . 

a.  Only  one  of  the  fifteen  Telecommunications  Center 
Requirements  shows  full  commonality: 

DD  173/JANAP  128  Conversion. 

Like  the  AUTODIN  System  Requirement  Functions,  this  function 
had  a  DoD  standard  to  guide  implementation. 

b.  Of  the  remaining  14  functions,  two  show  significant 
differences  in  performance.  These  are: 

(1)  JANAP  128/ACP  127  Conversion.  This  function 
was  listed  in  Part  1,  however,  the  data  submitted  for 

the  Phase  II  AMPE  Comparison  Study  indicates  that  no  AMPE  uses 
the  function.  It  will  be  dropped  as  an  AMPE  function.  The 
capability  is  present  in  the  AUTODIN  ASC. 

(2)  SI  Traffic.  The  data  submitted  indicates  that 
this  function  is  available  in  STREAMLINER  and  LDMX/NAVCOMPARS . 
Also,  the  AMME  will  be  modified  to  handle  SI  traffic;  the  ATP 
has  no  present  requirement  for  this  function,  but  is^  reviewing 
the  need  for  this  capability. 

c.  The  remaining  12  o<"  the  15  Telecommunications  Center 
Functions  exhibit  varying  degrees  of  commonality.  These 
functions  are: 

(1)  Distribution  Determination  of  Incoming  Messages 

(2)  Automatic  distribution  of  Incoming  Messages 

(3)  PLA/RT  Conversion 

(4)  Internal  Distribution  of  Outgoing  Messages. 
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(5)  Readdressal/Retransmission 

(6)  Statistical  Files 

(7)  Intransit  Storage 

(8)  Overflow  Protection 

(9)  Automatic  Service  Message  Generation 

(10)  Automation  Assisted  Traffic  Management 

(11)  Message  Retrieval 

(12)  Alt  Route  Capability 

d.  As  a  result  of  the  analysis  of  each  function  there 

is  a  distinct  commonality  exhibited,  in  that  all  AMPEs  perform 
each  of  these  12  functions.  However,  there  is  less  than  full 
commonality  in  the  manner  in  which  these  functions  are  performed. 
In  the  absence  of  DoD  standardization  in  the  Telecommunications 
Center  Requirements  functions,  each  of  the  Services/Agencies 
developed  their  own  functional  design  to  meet  validated 
requirements. 

e.  Within  the  Telecommunications  Center  Requirements, 
there  are  three  functions  associated  with  the  determination 
and  distribution  of  incoming  and  outgoing  messages.  These 
distribution  functions  have  been  identified  by  Servi ce/ Agency 
Communicators  as  problem  areas,  since  some  Administrative 
Officers  exercise  a  degree  of  control  in  defining  the  speci¬ 
fication  and  use  of  these  functions.  An  analysis  of  these 
three  functions  indicated  the  following: 

(1)  Distribution  Determination  of  Incoming  Messages. 

This  is  a  function  which  determines  internal  routings ,  and 
records  distribution  on  messages.  The  disparities  can  be 
recognized  by  examination  of  the  parameters  used.  AMME  uses 
PLA,  RI ,  Official  Title  and  Office  Symbol  to  route  narrative 
traffic;  and  uses  three  parameters  (CIC,  DSRI ,  OSRI)  for  data 
traffic.  LDMX  is  data  base  dependent,  using  text  analysis, 
as  well  as  the  RI ,  side  route  and  short  title.  The  ATP  uses 
the  RI ,  plus  message  elements  (OPR  address,  info  address,  and 
exempt  address).  ATP  proposes  to  use  a  Subject  Identifier 
(SID)  group.  STREAMLINER  establishes  internal  routing  based 
upon  a  unique  3-letter  (trigraph)  indicator  in  Format  Line  4a. 

(2)  Automatic  Distribution  of  Incoming  Messages. 

This  function  refers  to  the  capability  of  ar.  AMPE  to  make 
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internal  distribution  of  incoming  messages  with  a  minimum  of 
human  intervention.  The  use  of  this  function  can  be 
gauged  by  the  ratio  of  messages  delivered  without  human 
intervention. 


(a)  In  AMME ,  distribution  to  users  is  automatic 
for  messages  where  distribution  has  been  determined.  Messages 
not  automatically  distributed  are  referred  to  traffic  manage¬ 
ment  position  for  operator  intervention.  However,  this  analysis 
is  limited  because  the  percentage  of  automatic  distribution 
is  not  available. 


(b)  Another  example  is  that  this  function  is  fully 
automatic  in  LDMX/NAVCOMPARS ,  with  default  for  operator 
assistance  to  VDT.  Further  default  to  service  position  if  VDT 
operator  unable  to  process.  Consequently,  94%  of  messages  handled 
are  routed  automatically. 


(c)  In  ATP,  distribution  to  users  is  automatic 

for  messages  which  distribution  has  been  determined.  Successful 
automatic  distribution  can  approach  100%,  since  it  is  only  limited 
by  the  array  with  where  the  user  builds  his  file.  Messages 
not  automatically  addressable  by  user  file  reference  are 
displayed  for  operator/distribution  officer  distribution 
determination  via  KVCT. 

(d)  In  STREAMLINER  the  incoming  RI  is  examined  and 
the  associated  DDI  is  compared  with  the  DDI  on  Format  Line  4A, 
and  if  matched,  the  associated  distribution  is  appended  for 
output.  If  no  match,  message  goes  to  CRT  for  operator  inter¬ 
vention.  In  STREAMLINER,  98%  of  messages  are  automatically 
distributed. 


(3)  Internal  Distribution  of  Outgoing  Messages. 
Function  includes  all  methods  of  distribution  of  copies  of 
outgoing  messages  to  offices/agencies  within  the  origination 
command. 


(a)  AMME  uses  routing  and  distribution  file ,  and 
narrative  distribution  parameters:  RI ,  AIG,  Official  Title, 
and  Office  Symbol.  AMME  routes  Data  Traffic  by  DPI  Preamble. 

(b)  LDMX  permits  user  to  add  back  scatter 
distribution  in  "DISTR"  block  of  DD  173.  The  LDMX  can  use 
the  action  or  info  line  addressees  to  determine  back  scatter 
distribution . 


(c)  ATP  permits  addition  of  local  RI ,  and  use  of 
message  distribution  function.  With  OCR,  originator  can 
specify  come-back  copy.  ATP  does  not  read  or  recognize 
distribution  block  on  DD  173,-  however,  t-his  capability  could 
be  readily  provided. 
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(d)  STREAMLINER  performs  function  by  originator 
option  on  a  per  input  line  basis. 

f.  The  three  distribution  type  functions  have  been 
discussed  in  a  group;  however,  it  is  useful  to  discuss  the 
remaining  nine  functions  separately. 

(1)  PLA/RI  Conversion.  All  AMPEs  perform  the  function 
with  different  capacities  and  features.  Reporting  of  capac¬ 
ities  used  different  definitions  of  parameters.  For  example, 
the  maximum  number  of  PLA  or  RIs  stored  vary  from  500  maximum 
RIs  (AMME)  to  32,000  PLAs  (LDMX) .  STREAMLINER  reports  no 
limit  on  maximum  PLA/RIs  size.  ATP  reports  a  maximum  of  10,000 
PLA-Rls , limited  only  by  available  auxiliary  storage.  STREAMLINER 
includes  the  RI  in  the  PLA  table. 


Readdres sal /Retransmission . 


(a)  Readdressal .  In  AMME,  readdressal  is  manual, 
performed  by  operator.  ATP  has  no  on-line  message  files,  so 
the  function  is  manually  performed  by  service  message  or  KVDT 
input.  LDMX  accomplishes  this  function  by  entering  the  modified 
ACP  126  readdressal  request.  This  causes  LDMX  to  retrieve  the 
message  from  on  line  file,  append  the  appropriate  RIs  and 
releases  the  message.  In  STREAMLINER,  the  message  is  retrieved 
from  on  line  file,  the  operator  adds  readdressal  heading  to 
original  message  text,  and  reintroduces  message  into  the 
system. 


(b)  Retransmission.  Retransmission  in  ATP  is 
manual.  The  AMME  operator  retrieves  message  from  on-line  file, 
types  in  retransmission  command,  and  releases  message.  System 
routes  on  new  RIs  using  original  message  text.  Any  message  sent 
by  LDMX  may  be  retransmitted  from  VDT  position.  Retransmission 
instructions  are  appended  to  message  text  after  retrieval  from 
on  line  storage,  and  released  to  system.  NAVCOMPARS  provides 
unique  support  for  retransmission  and  operator  controlled 
retransmission  is  available.  STREAMLINER  automatically  recog¬ 
nizes  retransmission  request  and  retransmits  message  auto¬ 
matically.  Also  retransmits  when  open  message  numbers  are 
found. 


(3)  Statistical  Files.  All  AMPEs  have  extensive  capa¬ 
bility  for  storing,  retrieving,  and  generating  statistical 
files.  There  is  little  commonality  in  the  manner  in  which 
function  is  performed,  or  in  the  statistics  maintained.  The 
basis  for  the  establishing  statistical  files  is  not  uniform, 
as  reported  for  this  study.  For  example: 


-  LDMX  and  ATP  files  are  based  on  the  number 
of  messages. 

-  AMME  files  based  on  number  of  line  blocks. 

-  STREAMLINER  files  based  on  number  of  messages/ 
groups . 

(4)  In  Transit  Storage.  All  AMPEs  provide  in  transit 
storage,  utilizing  different  storage  media.  AMME  and  ATP 
store  on  a  disk,  LDMX  simultaneously  on  two 

disks,  and  STREAMLINER  stores  on  a  drum,  then  on  a  disk.  In 
addition,  all  AMPEs  provide: 

-  Storage  function  before  acknowledgement  (ACK) . 

-  History  or  journal  tapes  for  recovery  and 
historical  files. 

(5)  Overflow  Protection.  AMME  and  LDMX  require 
operator  intervention.  AMME  notifies  console  operator  when 

in  transit  file  exceeds  predetermined  saturation  point.  Operator 
can  provide  space,  using  system  purge  routine,  by  removing  all 
delivered  messages  from  disk  intransit  file.  LDMX  uses  an 
intercept  queue,  and  processes  the  queue  if  overload  is  approached. 
STREAMLINER  uses  a  disk  to  back  up  the  drum  in  the  event  an 
overload  is  approached.  ATP  provides  function  by  writing  an 
overload  tape,  if  operator  does  not  initiate  action. 


(6)  Autoi;.  .t ~.c  Service  Message  Generation.  ATP  auto¬ 
matically  generates  service  message  to  input  terminal  on  detection 
of  errors.  AMME  automatically  generates  service  messages  at 
header  validation  time.  STREAMLINER  performs  numerous  checks 
and  some  special  security  checks  which  result  in  automatic 
service  message  generation.  Both  STREAMLINER.  and  LDMX/NAVCOMPARS 
perform  similar  services  in  support  of  Navy  broadcast  feature. 

ALL  AMPEs  route  service  message  to  console  positions  or  to 
AMPE  printer  as  reouired.  LDMX  uses  this  function  for  FLASH 
acknowledgement.  'See  also  Para  2a(5)  FLASH  and  Higher 
Preemption) . 

(  / )  Auto;,  .tion  Assisted  Traffic  Management.  Both  AMME 
and  ATP  perform  this  automated  function,  while  STREAMLINER  and 
LDMX/NAVCOMPARS  furaiuh  statistics  on  operator  request.  ATP 
generates  statistics  automatically  every  30  minutes.  AMME 
generates  some  stot: sties  automatically  on  a  periodic  basis 
while  othur  stati.  _ ics  are  available  on  request.  Some  statis¬ 
tics  involve,  hardware,  most  involve  system  activity,  queue 
;  cat  as  .to  J  other  operational  statistics.  Function  is  very 
useful.  •  ui  iifftent  in  all  AMPEs. 


(8)  Message  Retrieval.  AMME,  LDMX  and  STREAMLINER 
perform  message  retrieval  function  on-line,  while  ATP  is  planning 
similar  enhancement.  Statistical  data  on  message  retrieval 
function  are: 

-  AMME  retrieves  past  120  hours  narrative  and  past 
6  hours  data  traffic. 

-  LDMX  retrieves  on-line  if  resident  on  message  disk 
(10-15  days) 

-  ATP  will  retrieve  last  30,000  messages  on-line 
(planned  enhancement) 

-  STREAMLINER  reports  a  variable  retrieval  period 
based  on  local  equipment  configuration  and  traffic 
volume . 

(9)  Alt  Route  Capability.  Alt  routing  functions 
under  operator  control  in  all  AMPEs.  , ATP  can  also  initiate 
function  by  card  input  which  results  in  system  configuration. 
STREAMLINER  assigns  logical  destination  to  alternate  transmit 
channel.  AMME,  LDMX,  and  ATP  uses  a  variety  of  alt  route 
parameters,  such  as:  RI ,  SSI,  Channel  ID,  Precedence  Group. 

These  can  be  used  individually  or  in  combination, 

4.  Customer  Assistance  Requirements.  Nine  functions  were 
designated  Customer  Assistance  Requirement  functions.  The 
following  analysis  indicates  little  standardization  in  the 
performance  of  these  functions. 

a.  Three  of  these  Customer  Assistance  Requirements  are 
unique,  and  not  common  to  all  AMPEs,  while  the  other  five 
functions  show  variations  in  the  manner  of  performance. 
Specifically,  the  following  Customer  Assistance  Requirement 
functions  are  considered  unique:  Broadcast  Keying;  Ship-to- 
Shore  Communications,  and  On-Line  Locator. 

(1)  Broadcast  Keying  is  unique  to  NAVCOMPARS  and 
STREAMLINER. 

(2)  Ship-to-Shore  Communications  is  unique  to 
NAVCOMPARS  and  STREAMLINER. 

(3)  On-Line  Locator  is  unique  to  NAVCOMPARS. 

b  Within  the  remaining  six  functions  some  commonality 
exists,  but  many  variations  are  noted.  These  six  functions 
are:  User-to-User  Service,  Automatic  Supervision  of  Message 

Preparation;  Message  Mask  Call-up  from  Remotes;  Electrical 
Interface  with  Data  Processors;  Preprocessing  of  Magnetic 
Tape  Traffic;  and  Automated  ACP  117  Maintenance. 
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(1)  User-to-User  Service.  ATP  and  LDMX/NAVCOMPARS 
and  STREAMLINER  use  RIs  for  routing  messages  between  remotes; 
AMME  uses  a  single  card  CSU  connection  request  to  establish 
connection.  ATP  can  handle  multiple  routed  messages,  using 
line  segregation  concept.  LDMX  handles  user-to-user  messages 
in  a  similar  manner  as  other  messages  are  handled;  in  that 
messages  are  queued  FIFO  to  output  channels,  are  accepted  in 
JANAP  128  or  Modified  ACP  126  formats.  SRT  can  initiate  this 
mode  (CSU)  via  a  system  control  message. 

(2)  Automatic  Supervision  of  Message  Preparation.  All 
AMPEs  provide  some  assistance  to  the  message  writer,  but  the 
STREAMLINER  provides  assistance  only  to  OCR  message  preparation. 
Others  provide  some  sort  of  on-line  assistance.  LMDX/NAVCOMPARS 
provides  an  automated  service  to  VDU  operator  at  the  AMPE, 

and  also  provides  service  to  OCR  preparation.  ATP  provides 
service  in  event  of  input  error.  Also  provides  manual  assis¬ 
tance  in  return  copy  of  DD  173.  AMME  and  ATP  offers  diagnostic 
messages  in  plain  language  to  assist  operators  at  SRTs  and  IRTs. 
ATP  and  AMME  have  the  most  capability  in  the  performance  of 
this  function. 

(3)  Message  Mask  Call-up  from  Remotes.  LDMX  does  not 
provide  this  function,  since  the  message  masks  reside  in  the 
Remote  Information  Exchange  Terminal  (RIXT) .  AMME,  ATP,  and 
STREAMLINER  all  provide  a  mask  for  DD  173.  In  addition,  AMME 
provides  an  IRT  and  SRT  mask,  ATP  provides  a  JANAP  128  and 
ACP  127  mask.  In  ATP,  users  may  also  store  varied  DD  173 
masks  which  cannot  be  used  by  others.  STREAMLINER  provides 

a  series  of  masks,  classified  as:  OCR/CRT  Simulator  Mask, 

CRITIC  Format,  Message  Fix,  and  CRT  Protocol. 

(4)  Automated  ACP  117  Maintenance.  AMME  performs  the 
RI  table  update  in  background  routine,  using  operator  initiation 
LDMX  performs  most  updates  on  line,  but  cannot  add  a  short  title 
on  line.  ATP  performs  update  on  line,  or  via  OCR,  which  include 
additions,  deletions,  and  chanqes.  A,T1P  records  those  PLA  and 
AIG  which  are  not  maintained  and  provides  a  later  print  out  of 
these  requests.  STREAMLINER  performs  this  function  either  on 
line  or  off  line. 

(5)  Electrical  Interface  with  Data  Processors.  All 
AMPEs  have  some  capability  to  support  this  function,  but 
variations  are  noted.  AMME  accepts  unique  preamble  format 
preceding  the  DPI  traffic,  then  formats  the  DPI  traffic  IAW 
JANAP  128  G.  ATP  provides  function  for  WKMCCS ,  and  is  readily 
expandable  for  other  users.  I.DMX/NAVcOMPARS  does  not  support 
the  function,  since  ,*  jf.  limited  to  data  pattern  (card  image) 
traffic  only.  STR  AM! .  INER  also  supports  the  function. 
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(6)  Preprocessing  of  Magnetic  Tape  Traffic.  AMME 
has  capability  of  sorting  traffic  prior  to  output  to  DPI; 
although  DPI  may  request  transmission  using  unique  preamble. 
LDMX/NAVCOMPARS  magnetic  tape  processing  is  limited  to  data 
pattern  (card  image)  only.  Files  of  traffic,  stored  in  data 
pattern  may  be  transmitted  to  remotes.  ATP  supports  function 
from  AUTODIN  to  remotes  and  from  remotes  to  AUTODIN.  STREAM¬ 
LINER  does  not  support  function. 


c.  The  two  data  processing  support  functions  above  were 
also  reviewed  with  reference  to  the  provisions  of  JCS  MOP  165, 
which  is  quoted  in  part: 


Para.  2. a.  "AUTODIN  will  be  used  to  satisfy  narrative 
record  and  data  communications  requirements 
unless  it  is  determined  that  AUTODIN  cannot 
meet  the  requirements." 


Para.  3.d.  lists  the  functions  that  an  AMPE  may  provide 
if  required. 


Para.  2.j.  "Pre-processing  and  post-processing  services 
of  DPI  will  not  normally  be  provided  by  the 
AMPE.  However,  where  feasible  and  mutually 
agreed  upon,  this  processing  may  be  provided 
by  the  AMPE." 
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APPENDIX  3 

I  ASA 


TELECOMMUNICATIONS  FUNCTIONS 


APPENDIX  3 


1  •  This  appendix  lists  the  baseline  telecommunications 
functions  required  in  the  near-term  (1978-83)  Integrated 
AUTODIN  System.  The  functions  have  been  identified  and 
allocated  to  the  elements  of  the  baseline  architecture  con¬ 
sisting  of  terminals  and  nodal  facilities  with  an  AUTODIN  II 
backbone  (Part  1) ,  and  further  categorized  by  priority 
(Part  2) . 

2.  Description  of  Elements. 

a.  Nodal  facilities  include  AUTODIN  II  Packet  Switching 
Nodes,  AOTODIN  I  ASCs  and  AMPEs .  Part  1  contains  the  func¬ 
tions  assigned  to  one  or  more  of  these  elements. 

b.  Terminals  include  all  elements  of  the  baseline  archi¬ 
tecture  at  which  record  traffic  is  entered  into  the  system 

or  which  directly  service  message  addressees.  Included  are 
telecommunications  centers  which  have  no  remote  terminals , 
remote  terminals  served  by  a  nodal  processor,  host  processors, 
and  terminals  of  a  host  processor  not  directly  connected  to  AUTODIN. 

c.  Some  functions  are  necessarily  performed  by  all  ele¬ 
ments  of  the  architecture. 

3.  The  categories  of  telecommunications  functions  listed  in 
Part  2  are  defined  as  follows: 

CATEGORY  I:  Minimum  Essential.  Those  functions  required 
to  support  the  basic  IAS  architecture. 

CATEGORY  II:  Operative  Functions.  Those  functions 
designed  to  minimize  operational  effort  and  to  maximize 
effective  and  efficient  service. 

CATEGORY  III:  State-of- the-Ar t .  Those  functions  that 
depend  on  the  developing  state-of-the-art  and  may  be  validated 
in  the  future  as  a  Minimum  Essential  or  Operative  Function. 

Allocation  of  functions  in  any  of  the  three  categories  may 
change  as  the  architecture  evolves  based  on  changing  require¬ 
ments  or  state-of-the-art. 
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PART  1 


ALLOCATION  OF  TELECOMMUNICATIONS  FUNCTIONS  (BASELINE) 

NODAL  FUNCTIONS 


FUNCTION 

Multipoint  Circuit 
Automatic  Dialing 


Data  Network  Interface 


Commercial  Interface/ 
Refile 

Alternate  Routing 


Intercept 


Conteriu  Addressing 
PLA/RI  Conversion 


DESCRIPTION 


Terminals  share  a  single  circuit. 

Acknowledge  completion  of  connection. 
Function  includes:  recognition  of 
ringing  signal,  answering  incoming 
calls,  generating  positive  response. 

Provide  medium  for  traffic  exchanges 
with  a  terminal  or  node  which  is  an 
integral  part  of  a  separate  data 
network . 

Functions  required  to  introduce  a 
message  from  the  IASA  into  a  common 
carrier  record  network. 

A  process  whereby  substitute  routes 
are  used  for  transmitting  messages 
when  the  terminal  fails  or  when 
circuit  failures  occur  on  primary 
transmission  paths  or  backlogs  develop 

Interim  storage  for  traffic  whose 
delivery  has  been  halted  by  operator 
or  system  command.  When  intercept 
condition  is  revoked  delivery  is 
initiated.  Provides  capability  to 
temporarily  hold  traffic  for  a  tribu¬ 
tary  that  is  out  of  service;  and  to 
store  traffic  for  a  part-time  terminal 

Design  ion  of  addressee (s)  by  evalu¬ 
ation  <  message  contents. 

Conversion  from  a  plain  language 
address  to  a  coded  routing  indicator. 

Determine  action  and  info  addressees 
within  receiving  organizat ion ;  e.g., 
by  analysis  of  certain  fixed  field 
parameters  iound  in  message.  Com- 
M nui  ions  o‘r  parameters  may  be  used 


Local  Distribution 
Determination 


FUNCTION 


DESCRIPTION 


DPI  Interface 


Pre/Post  Processing 


Terminal  Identification 


to  ascertain  specific  destinations 
for  message.  The  order  in  which 
parameters  determine  destinations, 
the  relative  weighting  (if  any)  given 
to  each,  and  the  combinations  actually 
used  vary  depending  on  user  distribu¬ 
tion  requirements.  Appropriate 
handling  procedures  based  on  unique 
routing  indicators,  official  titles, 
office  symbols,  local  distribution 
parameters,  and  operator-initiated 
alternate  routing  based  upon  pre¬ 
determined  or  operator-provided 
destinations . 

The  function  whereby  an  information 
processor  is  interfaced  to  the  network 
processor.  Also  referred  to  as  data 
processing  installation  (DPI)  interface 

On-line  sorting  of  incoming  messages 
by  parameters  such  as:  precedence, 
classification,  content  indicator  code, 
language  media  format  code.  Media 
conversion  for  manual  interface  com¬ 
patibility  or  on-line  interface. 

Techniques  to  identify  each  terminal 
to  the  network. 


User  Identification 


Traffic  Segregation 


Statistical  Recording 


AGP  127/JANAP  128 


Techniques  for  verification  of  user 
authority  to  access  the  network. 

Function  providing  separation  of 
traffic  of  two  or  more  functionally 
different  communities  of  interest;  e.g. 
DSSCS  and  GENSER  traffic. 

Collection  and  evaluation  of  data 
concerning  the  flow  of  information 
in  the  network. 

Conversion  of  ACP  127  format  to  JANAP 
128  format  and  vice  versa. 


DD  Form  173  to  JANAP 
128/DOI-103 


Conversion  of  DD  Form  173  message  form 
to  JANAP  128  format  or  to  DOI-103 
format  (DSSCS  traffic) 


FUNCTION 


DESCRIPTION 


Message  Composition 
Assistance 

Retrieval 

Referencing 

Code  Conversion 


Query /Response 


Interactive  Exchange 


Teleconferencing 

E  Lectronically 
Supported 
Coordination 

Bulk  Data  Transfer 


Inserting,  deleting,  replacing  char¬ 
acters  in  message  text.  Could  be 
applied  during  message  composition 
or  error  correction. 

Message  retrieval  accomplished  on-line, 
in  real-time. 

Capability  to  retrieve  messages 
referenced  in  an  incoming  message  and 
provide  the  cutomer  with  the  incoming 
message  and/or  assign  the  same  distri¬ 
bution  as  assigned  to  the  referenced 
message . 

System  accept  input  from  Communications 
&  Data  Systems  and  provides  output  to 
that  system  in  ASCII  or  in  its  native 
language,  on  a  case-by-case  basis. 

Exchange  of  a  question  and  answer  with 
no  attempt  to  sustain  the  continuity 
of  the  information  transfer  process. 
Provides  capability  to  access  a  .distant 
data  base  with  a  question  and  receive  an 
answer  back  via  the  AUTODIN  system. 
Terminal  uses  an  abbreviated  header  from 
which  ASC  builds  a  JANAP  128  DOI-103 
(DSSCS)  formatted  header  and  routes 
message  to  proper  host  computer. 

The  rapid  exchange  of  information 
between  subscribers  in  a  conversa¬ 
tional  mode  versus  interactive  mode 
transfer  process  is  maintained. 

More  than  two  subscribers  connected 
together  in  a  conversational  mode. 

Provides  ability  to  electronically 
hand  off  messages  to  other  terminals 
for  coordination  of  release. 

The  transmission  of  files,  programs, 
processing  results,  or  data  bases 
from  one  computer  to  another  with 
transaction  lengths  ranging  from 
10  Kbits  to  100  Mbits. 
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FUNCTION 


DESCRIPTION 


Error  Checks  & 
Correction 


In  Transit  Storage 


Overflow  Protection 


Automatic  Service  Msg 
Generation 


Ship-to-Shore 

Communications 


On  Line  Locator 


Automation  Assisted 
Traffic  Mgmt. 


/'ntomated  Supervision 
o i  Message  Preparation 


Includes  all  system  provisions  for 
detecting  and/or  correcting  circuit/ 
transmission  errors,  maintaining 
message  accountability,  detecting 
security  violations,  maintaining 
message  integrity,  detecting  format/ 
header  errors  on  both  front  and  back 
side. 

Includes  the  storage  of  message 
traffic  during  the  period  beginning 
with  "start  of  message  out"  from 
the  ASC  and  ending  with  "end  of 
message  out"  at  the  AMPE. 

Includes  system  features  and  pro¬ 
cedures  which  enable  the  system  to 
continue  receipt  of  traffic,  either 
from  the  ASC  or  from  connected  remotes 
of  peripherals,  the  saturated  condition 
of  IAS  notwithstanding 

Includes  all  sytem  features  involved 
in  the  handling,  origination  and 
receipt  of  service  msgs  to/from  front 
side  of  back  side  of  AMPE. 

Includes  system  capabilities  which 
permit  the  transmission  and  reception 
of  AUTODIN  messages  between  a  land 
homed  telecommunications  center  and 
seaborne  customers. 

System  capability  which  permits  the 
maintenance  of  a  unit  locator  system 
in  a  mobile  situation,  on-line  up¬ 
dating  of  a  subset  of  ACP  117. 

Includes  ail  system  features  which 
enable  or  assist  traffic  management. 


Includes  system  features  which  provides 
the  message  writer  with  assistance  in 
entering  a  message  into  the  system. 


FUNCTION 


DESCRIPTION 


Message  Mask  Call-up  from 
Remotes 

(AMPE  Unique  Function) 


System  features,  either  in  the  remote 
or  in  AMPE  which  provide  masks  on  the 
screen  of  a  VDU  or  KVDT  to  assist  the 
remote  user  in  msg  entry. 


Automated  ACP  117 
Maintenance 
(AMPE  Unique  Function) 


Includes  all  system  resources  devoted 
to  maintenance  (automated,  automation 
assisted  or  manual)  of  ACP  117,  and 
any  resources  devoted  to  the  use  of 
ACP  117  in  PLA/RI  conversion. 
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TERMINAL  FUNCTIONS 


FUNCTION 
Card  Medium 

Paper  Tape  Medium 

Magnetic  Tape  (MT) 
Medium 


Variable  Length  MT 
Records 


Hard  Copy  (Paper) 

Computer  Output  to 
Microfilm  (COM) 

OCR  Input 

Logging 


DESCRIPTION 


Data  stored  on  punched  cards  is 
accepted  for  transmission;  received 
data  is  converted  to  punched  card  and 
if  required  hard  copy  output  for 
delivery  to  customers. 

Data  stored  on  paper  tape  is  accepted 
for  transmission;  received  data  is 
converted  to  paper  tape  and  if  required 
hard  copy  output  for  delivery  to 
customers . 

Data  stored  on  magnetic  tape  is 
accepted  for  transmission;  received 
data  is  converted  to  magnetic  tape 
for  deliver  to  customers.  Data  is 
blocked  with  a  fixed  or  variable 
number  of  characters  per  block 
changeable  on  a  site  by  site  basis. 

Data  stored  on  magnetic  tape  is 
accepted  for  transmission;  received 
data  is  converted  to  magnetic  tape 
for  delivery  to  customers.  Data -is 
blocked  with  the  number  of  characters 
varying  from  block  to  block,  within 
specified  maximum  and  minimum  limits. 

Received  data  is  converted  to  printed 
paper  copy  for  delivery  to  customers. 
Data  recorded  on  paper  is  accepted 
for  transmission. 

Received  data  is  converted  to  micro¬ 
film,  microfiche,  etc.,  for  delivery 
to  customers. 

Data  recorded  on  standard  message 
forms  is  converted  to  a  binary  stream 
for  direct  input  to  an  automated 
message  processing  system,  or  converted 
to  another  storage  medium,  such  as 
paper  or  magnetic  tape,  for  subsequent 
input  to  a  message  processing  system. 

Maintaining  a  continuous  printout  of 
events  associated  with  terminal  pro¬ 
cessing.  Used  by  terminal  operators. 
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FUNCTION 


DESCRIPTION 


Digital  Facsimile 


Video  Transmission 


Digital  Voice 

Telemetry 


Transmission  of  images  as  a  digital 
bit  stream.  The  image  is  scanned 
at  the  transmitter,  converted  from 
an  analog  to  a  digital  state,  recon-  ^ 
structed  at  the  receiving  station,  and 
duplicated  on  hard  copy. 

Transmission  of  non-sinusoidal  wave¬ 
forms  involving  Megahertz  frequencies; 
i.e.,  the  transmission  of  a  digitized 
wideband  signal. 

Transmission  of  an  analog  voice 
signal  which  has  been  converted  to 
a  digital  form  for  transmission. 

Transmission  of  binary  data  derived 
from  remote  sensing  of  operating 
equipment . 
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PERVASIVE  FUNCTIONS 


FUNCTION 

Mode  I  Operation 


Mode  II  Operation 

.. 

Mode  V.  Operation 


Mode  IB  Operation 
Mode  IIA  Operation 

Mode  VI  Operation 


DESCRIPTION 


Duplex  synchronous  operation  with 
automatic  error  and  channel  controls 
which  allow  independent  and  simul¬ 
taneous  two-way  traffic  flow.  Accom¬ 
plished  by  means  of  control  characters, 
which  are  used  to  acknowledge  receipt 
of  valid  line  blocks  and  messages  or 
to  return  error  information.  Terminal 
or  ASC  respond  automatically  to  these 
characters  by  continuing  or  stopping 
transmission  or  displaying  action 
information  to  the  operator. 

Duplex  asynchronous  operation  without 
the  automatic  error  and  channel  con¬ 
trols  which  allow  independent  and 
simultaneous  two-way  traffic  flow. 
Message  accountability  maintained 
through  channel  sequence  numbers  and 
service  message  actions. 

Duplex  asynchronous  or  synchronous 
operation,  also  called  the  teleprinter 
controlled  mode,  which  offers  character 
framing,  detection,  channel  controls, 
and  independent  and  simultaneous  two- 
way  traffic  flow;  control  characters 
used  to  acknowledge  receipt  of  messages 
and  to  display  limited  information  to 
the  operator.  Message  accountability  is 
maintained  through  the  use  of  channel 
sequence  numbers  with  automatic  response 
using  control  characters  by  the  distant 
terminal/ASC .  Error  control  is  not 
provided . 

IBM  Bisync  or  ANSI  X3. 28-1971 
communications  control  procedures. 

Asynchronous  mode  AlITODIN  II  communi¬ 
cation  control  procedures.  (10  or  11 
bit  ASCII) . 

Synchronous  mode  AUTODIN  II  communi¬ 
cations  control  procedures.  (ADCCP , 
independent  numbering) . 
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FUNCTION 


DESCRIPTION 


Full  Duplex 
Half-Duplex  * 

Simplex 

Multiple-Destination 

Addressing 

Broadcasting 

Collective  Addressing 

Dual  Homing 


Multiple  Precedence 
Levels 


Priority  Interrupt 


Mail  Box  Service 


Transmission  may  occur  on  a  circuit 
in  both  directions,  simultaneously. 

Transmission  may  occur  on  a  circuit 
in  both  directions,  but  not 
simultaneously. 

Transmission  may  occur  on  a  circuit 
in  one  direction  only. 

A  technique  wherein  information  may 
be  entered  once  at  the  terminal  and 
is  directed  to  several  destinations. 

For  example,  several  routing  indi¬ 
cators  in  a  message  header. 

A  method  of  transmitting  messages/ 
information  to  a  number  of  receiving 
stations . 

A  technique  wherein  a  number  of 
destinations  may  be  addressed  by  a 
single  code,  for  example,  addressee 
indicator  group  (AIG) . 

A  technique  whereby  a  telecommunications 
center  is  provided  access  to  two  net¬ 
work  nodes  either  by  having  two  ter¬ 
minals,  each  of  which  is  homed  to  a 
different  node  or  a  single  terminal 
homed  to  two  nodes . 

A  technique  wherein  more  than  one 
precedence  classification  is  assigned 
to  information  flowing  in  the  network. 
Information  is  routed  and  delivered 
in  a  first  in,  first  out  by  precedence 
manner . 

This  function  will  suspend  processing 
of  a  lower  precedence  message  when  a 
message  carrying  a  specified  higher 
precedence  enters  system,  and  returns 
to  interrupted  message  when  processing 
is  completed,  at  the  point  of  interrup¬ 
tion  or  beginning  of  message,  through 
multiple  levels  of  precedence. 

Traffic  is  held  for  delivery  on  an 
on-call  basis. 
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FUNCTION 

Retransmission 

Privacy  of  Traffic 


Journaling 


Audit  Trail 


History 

decayed  Data  Removal 


DESCRIPTION 

The  repetition  of  a  message  previously 
transmitted. 

AUTODIN  I  implementation  is  AUTODIN 
limited  privacy  service  (ALPS)  which 
will  allow  special  compartmented 
traffic  to  pass  through  the  AUTODIN 
system  without  being  recorded  on 
history  or  log  tapes.  Provides  limited 
amount  of  privacy  since  no  recorded 
copy  will  exist.  AUTODIN  II  will 
inherently  support  this  function  since 
there  is  not  secondary  storage  in  the 
switching  network . 

The  storage  of  a  copy  of  transmitted 
and  received  information  and  a  record 
of  the  processing  events  associated 
with  each  message.  Examples  of 
entries  would  be  start  of  input,  end 
of  input,  start  of  output,  end  of 
output.  The  journal  is  balanced  for 
traffic  analysis  and  for  recovery 
after  system  failure.  Provides  audit 
trail . 

Function  provided  by  journaling 
whereby  messages  logged,  e.g.,  on 
magnetic  tape  as  received,  carried  as 
open  entries  until  successfully 
delivered.  Uhen  message  acknowledged 
by  end  device,  or  in  case  of  uncon¬ 
trolled  circuits,  when  message  output 
completed,  event  is  recorded  on  tape 
as  closing  entry.  During  processing, 
while  message  is  in  system,  internal 
lists  and  tables  of  message  status 
constantly  updated. 

Maintenance  of  a  complete  copy  of 
transmitted  and  received  traffic. 

Ability  to  remove  or  update  messages 
which  are  outdated  or  no  longer 
needed  for  backup.  This  includes 
data  stored  anywhere  in  the  system. 
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FUNCTION 


DESCRIPTION 


Code  Independent 
Transmission 

Logical  Addressing 


Network  Virtual 
Terminal 


On-Line  Delivery- 


Bit  oriented,  data  code  independent 
transmission. 

Addressing  capability  in  which  a 
subscriber  is  assigned  a  single 
logical  address,  regardless  of  physical 
address .  The  network  accomplishes  the 
translation  from  logical  to  physical 
addressees  for  delivery. 

Intercommunications  between  normally 
incompatible  terminals  by  mapping 
each  into  and  out  of  a  network  standard 
imaginary  device  termed  a  "network 
virtual  terminal." 

On-line,  real-time  subscriber-to- 
subscriber  delivery,  with  immediate 
delivery  acknowledgement  from  desti¬ 
nation  node  to  the  originating 
subscriber. 
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PART  2 


CATEGORY  I:  MINIMUM  ESSENTIAL  FUNCTIONS 
NODAL  FUNCTIONS 


Terminal  Identification 

User  Identification 

Traffic  Segregation 

Statistical  Recording 

ACP  127/JANAP  128 

Commercial  Interface/Refile 

Code  Conversion 

Alternative  Routing 

Intercept 

Retrieval 

On  Line  Locator 
(AMPE  Unique  Function) 

Audit  Trail 


Bulk  Data  Transfer 
Query /Response 
Interactive  Exchange 
Error  Checks  &  Correction 

In  Transit  Storage 

1 

Overflow  Protection 


Automatic  Service  Msg 
Generation 


Ship-to-Shore  Communications 
(AMPE  Unique  Function-Navy) 


TERMINAL  FUNCTIONS 


Card  Medium 
Paper  Tape  Medium 
Magnetic  Tape  (MT)  Medium 
Variable  Length  Ml'  Records 
Hard  Copy  (Paper) 

Logging 

Automation  Assisted  Traffic 
Management 

(AMPE  Unique  Function) 


Automated  Supervision  of 
Message  Preparation 
(AMPE  Unique  Function) 

Message  Mask  Call-up  from 
Remotes 

(AMPE  Unique  Function) 

Automated  ACP  117  Maintenanc 
(AMPE  Unique  Function) 


-147- 


PERVASIVE  FUNCTIONS 


Mode  I  Operation 
MODE  II  Operations 
Mode  V  Operation 
Mode  IB  Operation 
Mode  VI  Operation 
Full  Duplex 
Half-Duplex 
Simplex 

Multiple-Destination  Addressing 


Collective  Addressing 
Dual  Homing 

Multiple  Level  Precedence 

Priority  Interrupt 

Retransmission 

Journaling 

Audit  Trail 

History 

Mode  IIA 


CATEGORY  II:  OPERATIVE  FUNCTIONS 
NODAL  FUNCTIONS 

Multipoint  Circuit  DPI  Interface 

PLA/RI  Conversion  Pre/Post  Processing 

Leal  Distrubution  Determination  DD  Form  173  to  JANAP  128 


TERMINAL  FUNCTIONS 


OCR  Input 
Digital  Facsimile 
Privacy  of  Traffic 


Code  Independent 
Transmission 

Logical  Addressing 


CATEGORY  III:  STATE-OF-THE-ART  FUNCTIONS 
NODAL  FUNCTIONS 

Message  Composition  Automatic  Dialing 

Assistance 
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Content  Addressing 
Referencing 


Teleconferencing 


Electronically  Supj' >•  rted 
Coordinated 


TERMINAL  FUNCTIONS 


Computer  Output  to  Microfilm 
(COM) 

Video  Transmission 
Digital  Voice 
Telemetry 


Broadcasting 
Mail  Box  Service 
Decayed  Data  Removal 
Network  Virtual  Terminal 
On-Line  Delivery 
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